JSON اسکیما ویلیڈیٹر

Every failure at once, not just the first one

Rather than stopping at the first rule a document breaks, the [msm_tool slug="json-validator"] walks the whole document against the whole schema and reports every failure it finds, each with the exact path where it occurred. That is what makes fixing a large document practical: a single pass shows every field that needs attention instead of one at a time across repeated runs.

Silence means the rules passed, not that the rules were good

A schema with no required properties and open-ended object rules accepts nearly anything, and an empty schema accepts everything without exception. A document reported as valid against either has only cleared a low bar — passing means the data satisfied whatever was actually written, which is worth checking on its own terms before trusting the result too far.

Only references within the same document resolve

A `$ref` pointing somewhere else inside the same schema works as expected. One pointing at an external URL or a separate file cannot be fetched from inside the validator, and rather than being silently skipped, it is reported as unresolvable — a schema that depends on an external reference needs that reference inlined before a complete result is possible here.

format is a note, not a rule, by default

In JSON Schema, the `format` keyword is an annotation rather than an assertion unless something specifically turns it into one. Marking a field as an email format documents the intent without actually rejecting a malformed address; a `pattern` is what enforces the shape of a value when the check genuinely needs to bite.

Invalid JSON never reaches the schema at all

A document that will not parse fails before any schema is applied, and the parser's own error is shown rather than a schema-shaped one — it names the position in the text, which is usually enough on its own to find a stray comma or an unquoted key. A parse failure and a schema failure are different problems, and the message makes clear which one occurred.

Why one mistake can appear at several paths

Combinators such as `anyOf` try every branch in turn and report the failure from each one that did not match, so a single value can produce several reported failures if more than one branch was tried against it. The repeated paths point at the same location in the document rather than several separate problems.