JSON Schema Validator

Paste a JSON Schema on the left and the JSON you want to check on the right — or drop a .json file onto either pane. The draft is auto-detected from $schema (draft-04, draft-07, 2019-09, or 2020-12) with a manual override, and every failure is listed with its JSON Pointer path, the keyword that rejected it, and the line it sits on; click a path to jump straight to that value. Internal $refs into #/$defs and #/definitions are resolved, and formats the engine does not actually assert are called out as warnings instead of quietly passing. Nothing is uploaded — the validator runs in your browser. Need a schema first? The JSON Schema Generator infers one from a sample — just read what inference cannot know before trusting it. To tidy up messy JSON before validating, use the JSON Formatter, and to turn a validated shape into runtime models try JSON → Pydantic.

Reading the errors table

Each row is one reason the document was rejected. Instance path is an RFC 6901 JSON Pointer into your data — (root) for the whole document, /user/age for a nested field, /tags/1 for the second array element. Keyword is the schema keyword that failed, which tells you where to look in the schema: required and additionalProperties point at the object itself, while type, enum, minimum, and pattern point at the individual value.

A oneOf error is worth reading closely. “Instance does not match exactly one subschema (2 matches)” does not mean your data is wrong — it usually means the schema is: overlapping branches such as { "oneOf": [{ "type": "integer" }, { "type": "number" }] } match the same value twice, and anyOf was probably intended.

Why this validator does not compile your schema

Most JavaScript validators, including Ajv, get their speed by generating JavaScript source for your schema and compiling it with new Function. That is fast, but it needs a Content Security Policy that permits unsafe-eval — which this site does not grant. This page uses @cfworker/json-schema, a small MIT-licensed interpreter that walks the schema at runtime instead. The practical trade-off is throughput on very large documents, not correctness: it is tested against the official JSON Schema Test Suite.

Frequently asked questions

Which JSON Schema drafts are supported?

Draft-04, draft-07, 2019-09, and 2020-12. The draft is auto-detected from the $schema keyword in your schema, and you can override it with the Draft selector — the tool always shows which draft is actually in effect and where that choice came from. Draft-06 is validated using draft-07 rules (with a warning), and draft-03 is not supported: it falls back to 2020-12 with a warning, so results for a draft-03 schema may be misleading. If your schema has no $schema at all, 2020-12 is used.

Does it check the format keyword, like "email" or "date"?

Some of them, and it tells you when it does not. The validator asserts these 17 formats: date, date-time, duration, email, hostname, ipv4, ipv6, json-pointer, json-pointer-uri-fragment, regex, relative-json-pointer, time, uri, uri-reference, uri-template, url, and uuid. Any other format value — idn-email, iri, or a custom one — is not checked, and the tool raises a warning naming it so you never assume a value was validated when it was not. Note that the JSON Schema specification treats format as an annotation by default, so other validators may skip it entirely.

Why does one broken field sometimes produce fewer errors than I expected?

The underlying engine emits an error for every keyword on the way down to a failure, so a single bad nested value can produce a chain like "Property user does not match schema" → "Property age does not match schema" → "Instance type string is invalid". The tool collapses those wrapper errors and shows only the root causes, and the Invalid banner tells you how many raw errors were collapsed. Sibling failures are all reported — validation does not stop at the first error.

Are $ref, $defs, and definitions resolved?

Internal references are, including "#/$defs/Name" (2019-09 and 2020-12) and "#/definitions/Name" (draft-04 and draft-07), plus $id-based and $anchor references inside the same document. Remote references are not fetched: the page makes no network requests, so a $ref pointing at an external URL cannot be resolved and is reported as a schema error rather than being silently ignored. Paste the referenced subschema into $defs to validate locally.

Does my schema or data leave my browser?

No. The validator is a JavaScript library that runs entirely on this page — your schema and your JSON are never uploaded, and dropping a .json file reads it locally with the File API. Nothing is stored and there is no signup.