This checks a JSON document against a JSON Schema — a schema being itself a JSON document that describes what the data is allowed to look like. Rather than reporting only the first problem, it walks the whole document and reports every failure with the path where it occurred, which is what makes fixing a large document practical.
The keyword coverage is broad: types, required properties, numeric bounds, string length and pattern, array bounds and item schemas, enums and constants, property dependencies, and the combinators allOf, anyOf, oneOf, not and the if/then/else trio. Local references are resolved against the root schema, and a reference that cannot be resolved, or that recurses, is reported rather than silently skipped.
Limits worth knowing before you rely on it
-
Only local references resolve:
a $ref pointing into the same schema works. One pointing at a URL or another file cannot be fetched, and is reported as unresolvable rather than passed over.
-
Validation is not the same as parsing:
invalid JSON fails before any schema is applied. The parser's own message is shown, and it names the position, which is usually enough to find a stray comma.
-
A schema that permits everything reports nothing:
an empty schema is valid and accepts any document. Silence means the data passed the rules you wrote, not that the rules were adequate.
-
Format keywords are informational:
in JSON Schema, format is annotation rather than assertion by default. Do not rely on it to reject a malformed email address; use a pattern where the check must bite.
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.