JSON Schema Validator
Validate JSON against a JSON Schema with a real, spec-compliant engine — $ref, oneOf/anyOf/allOf, const, patterns, formats (Draft 4–2020-12).
How JSON Schema validation works
JSON Schema is a vocabulary for describing the structure of JSON data. Unlike a hand-rolled subset checker, this tool uses @cfworker/json-schema— a real, spec-compliant validator — so it enforces the full vocabulary: $ref/$defs, oneOf/anyOf/allOf/not, const, patternProperties, format, and all the numeric/string/array constraints. It auto-detects the dialect from $schema (Draft 4, 6, 7, 2019-09, or 2020-12), lists every failing location as a JSON Pointer, and runs entirely in your browser (no eval, no server).
To generate a JSON Schema from existing data, use JSON Schema Generator. For TypeScript types, try JSON to TypeScript.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Checking a payload against a contract before sending it, rather than after a service rejects it.
- Finding which field in a large document fails a constraint.
- Confirming a schema you wrote actually rejects the cases you intended.
- Testing a schema change against existing sample data before deploying it.
- Distinguishing a data problem from a schema problem when both are new.
Frequently Asked Questions
- What does it check?
- A JSON document against a JSON Schema — types, `required` properties, string and numeric constraints, array bounds, enums and nested object shapes — reporting each failure with the path to the offending value.
- Why did an unexpected property not fail?
- Because JSON Schema allows extra properties by default. Set `additionalProperties: false` if unknown keys should be rejected; leaving it open is intentional, since it lets a schema tolerate forward-compatible payloads.
- Why is a property optional when I declared its type?
- Because in JSON Schema a property definition describes a value if present, and only the `required` array makes it mandatory. This trips up almost everyone coming from a typed language.
- Does the order of errors mean anything?
- No, and a single mistake often produces several. Fix the outermost path first — a wrong type on a parent object cascades into every constraint below it, and most of those disappear together.
- Which draft does it target?
- The common core shared by the modern drafts — types, required, enums, and the numeric, string and array keywords. Draft-specific behaviour around `$ref` resolution and dynamic anchors is where implementations genuinely diverge.
- Is validation a substitute for server-side checks?
- No. Schema validation confirms shape, not permission or plausibility — a well-formed request can still be unauthorised or reference something that does not exist. It removes a class of errors, not the need to check the rest.
Common errors and gotchas
- Assuming unlisted properties are forbidden. Without `additionalProperties: false` they are allowed.
- Forgetting `required`, so a schema that describes every field still accepts an empty object.
- Mixing draft versions, where keyword behaviour differs and a schema silently does less than you think.
- Expecting format keywords to be enforced. In many implementations they are annotations by default.
- Reading a pass as complete validation, when the schema only checks what it was written to check.