JSON Schema Validator
Last updated: 2 October 2026
Check a JSON document against a JSON Schema and see every failed constraint with the path it failed at. The document and the schema are both parsed and checked in your browser.
What it checks
A JSON Schema describes the shape a document is allowed to have: which properties exist, what types they hold, and what ranges and patterns are acceptable. This page checks a document against a schema and lists every place it fails, each with a path so you can find it.
The supported keywords are: type, const, enum, required, properties, additionalProperties, minProperties, maxProperties, items (one schema, or a tuple of schemas), minItems, maxItems, uniqueItems, minLength, maxLength, pattern, minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf, allOf, anyOf, oneOf, not, and local $ref pointers into the same schema.
What it deliberately does not do
- No remote
$ref. Only pointers inside the same schema (#/$defs/…,#/definitions/…) are resolved. Fetching another file would mean a network request, which is exactly what this tool exists to avoid. formatis not an assertion. In recent draftsformatis annotated, not enforced, and that is how it is treated here — aformatofemaildoes not reject a malformed address.- Some keywords are not implemented:
patternProperties,unevaluatedProperties,if/then/else,dependentSchemas,contains. A schema that uses them still has its other keywords checked, but the unimplemented ones are not enforced — so do not read a pass here as full conformance for a schema built on them. - The schema is not meta-validated. A schema that is syntactically valid JSON but logically wrong may simply match nothing; this page checks the document, not the schema's own correctness.
Reading the errors
Each failure is reported at a path: $ is the document root, a dot walks into a property, and a bracket indexes an array. required is reported at the object that was supposed to contain the property — the constraint lives on the object, not on the missing property — with the property named in the message. anyOf and oneOf are reported once, at the instance that failed, rather than once per branch; a wall of branch errors hides the real one.
Frequently Asked Questions
Which JSON Schema keywords are supported?
type, const, enum, required, properties, additionalProperties, minProperties, maxProperties, items (a single schema or a tuple of schemas), minItems, maxItems, uniqueItems, minLength, maxLength, pattern, minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf, allOf, anyOf, oneOf, not and local $ref.
What is deliberately not supported?
Remote $ref (only pointers inside the same schema are resolved), the format keyword as an assertion, patternProperties, unevaluatedProperties, if/then/else and dependentSchemas. A schema that uses them still validates the keywords above; the unsupported ones are simply not enforced, so do not treat a pass here as a full conformance result for a schema built on them.
Is the validation done on a server?
No. Both the document and the schema are parsed with JSON.parse in your browser and checked in memory. Nothing is uploaded, and the page works with the network disconnected.
Why is a required-property error reported at the parent path?
Because that is where the constraint lives. JSON Schema applies required to the object, not to the missing property, so the error is reported at the object's path — for example $ rather than $.name — with the property named in the message.
How are anyOf and oneOf reported?
As one error at the instance that failed, rather than one error per branch. anyOf fails when no branch matches; oneOf fails when the number of matching branches is not exactly one, and the message says how many matched. Reporting every branch's internal errors would bury the real one.
Does it tell me the schema is wrong, or only the document?
It checks the document against the schema. If the schema itself is not valid JSON you are told that separately. It does not validate the schema against the JSON Schema meta-schema, so a schema that is syntactically fine but logically wrong may simply match nothing.
Need to compare two documents instead? JSON Diff does that. Spotted a bug? Get in touch.