JSON Schema Validator
Validate JSON against a JSON Schema, draft-03 through 2020-12, with Ajv — every violation (missing field, wrong type, bad format) by path, line and column.
You can also drop a .json or .yaml file onto either box.
Validate JSON against a schema
Paste a JSON document and a JSON Schema (either may be YAML instead — pick it in Document format or Schema format), and this tool checks the document against the schema instantly, listing every rule it breaks — a missing required property, a wrong type, a value outside minimum/maximum, or a string that fails a format such as email or date-time. Each violation is shown with the line and column where the offending value sits in your document and the JSON Pointer path to it, so you know exactly where to fix it. A document read as YAML has no JSON text to count lines in, so its violations are placed by the JSON Pointer alone.
Draft-03 through 2020-12
JSON Schema draft 2020-12, 2019-09, draft-07, draft-06, draft-04 and draft-03 are all supported. By default the draft is read from the $schema URI in your schema, and a schema with no $schema is validated as draft-07; the Draft select lets you name another, and the page says under the result which draft it used and why. Validation runs entirely in your browser using Ajv, so your data and schema never leave your device. This is the inverse of our JSON Schema Generator: that tool infers a schema from a sample, while this one checks a document against a schema you already have. It can also start from the schema alone: Make a sample document from this schema fills the document box with a document built from the schema — its keys, types, enums, formats and ranges — and checks it at once; a pattern is not filled in, so a field with one is listed as a violation to fix by hand. A .json or .yaml file can be dropped onto either box as well as opened.
Frequently asked questions
Which JSON Schema drafts are supported?
Draft 2020-12, 2019-09, draft-07, draft-06, draft-04 and draft-03. The validator reads the $schema URI in your schema and uses the matching Ajv build automatically; a schema with no $schema is validated as draft-07. Pick a draft from the Draft select to validate as that one whatever the $schema says. Ajv has no draft-04 or draft-03 build, so those schemas are translated into draft-06 before compiling — id becomes $id, a boolean exclusiveMinimum becomes the bound itself, and so on.
Why does it list every error instead of stopping at the first?
Validation runs with allErrors enabled, so all violations are collected in one pass. Each one is shown with its JSON Pointer path (for example /user/email) and Ajv’s own wording for the rule that was broken. The validator writes those in English, and they are shown verbatim — on the Korean page too — rather than paraphrased, so the line, column and path are what tell you where to look.
How do I find a violation in a long document?
Each row starts with the line and column where the value sits — for a property, its key, which is where you would look for it — and then gives the same place as a JSON Pointer such as /user/email; a document read as YAML gets the pointer alone. A key the schema does not allow is pointed at that key rather than at the object around it, and the copied report carries the line and column too.
Can it read YAML, resolve a $ref into another schema, or check many documents at once?
Yes. Document format and Schema format each switch their box from JSON to YAML. The box “Other schemas a $ref points to” takes a schema, or a list [ … ] of them, each with its $id, so a $ref such as https://example.com/address.json resolves. Tick “Several documents” and the document box is read as JSON Lines, a document per line, or as a YAML stream separated by ---. The result says how many documents do not match, each failing one is headed with its number (and, for JSON Lines, its line), and Copy and Download carry all of them.
Can it write a sample document from my schema?
Yes — press Make a sample document from this schema. The document box fills with a document that has every property the schema lists, plus any other required key, using the schema’s own const, default, examples or first enum value where it gives one, a stock value for each format, numbers inside minimum and maximum (and multipleOf), and lengths and item counts inside their bounds; local $refs, allOf and the first oneOf or anyOf branch are followed. The page checks it straight away. A pattern is not filled in, so a field with one appears as a violation to fix by hand, and a schema that asks for more than a sample can hold is cut short, with a note saying so.