Check a JSON document against a schema, with exact error locations
Quick answer: JSON Schema validation compares your document to a contract of type, required, properties, minimum, pattern and similar keywords, then reports every violation with a JSON-pointer path. Paste your schema on the left, the document on the right, and hit Validate. Nothing leaves your browser.
| draft-07 | 2019-09 | 2020-12 | |
|---|---|---|---|
| $schema URI | http://json-schema.org/draft-07/schema# | https://json-schema.org/draft/2019-09/schema | https://json-schema.org/draft/2020-12/schema |
| Reusable definitions | definitions | $defs | $defs |
| $ref siblings | Ignored ($ref overrides) | Applied alongside $ref | Applied alongside $ref |
items with partial validation | Not possible | prefixItems draft | prefixItems + items |
exclusiveMinimum | Number, e.g. 18 | Number | Number (same as -07) |
| Where you'll meet it | Most APIs, OpenAPI 3.0, Swagger | Transitional; some tooling | OpenAPI 3.1, modern tooling |
The biggest practical jump is OpenAPI 3.0 → 3.1: 3.0 is built on draft-07, 3.1 on 2020-12, so schemas written for one can misbehave under the other. Picking the dialect here matches what each specification expects.
A JSON Schema is a machine-readable contract: it states what a valid document must look like, and a validator answers the yes/no question, with reasons. This page runs Ajv (the same library that guards countless Node.js APIs) compiled for the browser, so results match what your production code would say.
First the schema itself is parsed and checked against its dialect's meta-schema, catching typos like reqired before they produce nonsense verdicts. Then the schema compiles into a validation function, and that function runs against your document. Each failed keyword produces an error carrying an instancePath (where in the document), a message (what went wrong), and params (the specific keyword values involved).
Paste the schema on the left and the document on the right. Choose a dialect or leave it on auto: auto reads your $schema declaration and falls back to draft-07 when there isn't one, matching Ajv's default. Hit Validate for a pass/fail verdict and, on failure, one line per problem with its pointer path.
Load the sample. The schema requires name and email, allows only those three properties (additionalProperties: false), and demands age be an integer of at least 18. The sample document ships three violations, and the validator reports exactly these:
/ must have required property 'email'/ must NOT have additional properties (nickname)/age must be >= 18 (the document says 17)Fix all three and the verdict flips to green. That pointer-first style is the point: instead of "validation failed", you get the branch of the document to walk to find each problem.
Paste your schema into the first box and the document you're testing into the second, then hit Validate. The validator checks the document against every applicable keyword (type, required, properties, minimum, pattern and so on) and reports each violation with its exact location, like /age must be >= 18. If the schema itself is malformed, you get a schema error instead.
Draft-07, 2019-09, and 2020-12, the three dialects you'll meet in practice. The tool reads your $schema declaration and picks the matching engine automatically; if there's no $schema, it assumes draft-07, which is still the most widely deployed dialect in APIs and configs.
No. Parsing and validation happen entirely in your browser with Ajv compiled to JavaScript. Nothing is uploaded, logged, or stored, which is why the page works even for payloads you couldn't paste into a shared paste-bin.
instancePath is a JSON Pointer to the exact spot that failed: an empty path means the document root, /items/2/price points at the price field of the third array item. Read it right-to-left as a breadcrumb from your document to the failing value.
In JSON Schema, format is annotation-only by default, so many validators skip it unless configured for assertions. This validator enables format checking for the common ones (email, date, date-time, uri, uuid) so bad values are caught, and rejects schemas that use formats it doesn't know about rather than silently ignoring them.
Not directly here, since the validator expects JSON. Convert first: our YAML validator converts YAML to JSON, and most pipelines keep a JSON export step anyway. The schema itself must be JSON as well, though $ref can point at YAML files in other tools.