Validate a JSON document against a JSON Schema (draft 2020-12 subset): types, required properties, enums, formats, constraints, allOf/anyOf/oneOf and local $refs — every violation listed with its location.
Show calculation steps
Processed privately in your browser — nothing you paste is uploaded, logged or stored.
Contract checking, violation by violation
Syntax can be perfect while the content breaks your API contract: a string where an integer belongs, a missing required field, an enum value that does not exist. Paste the document and the schema, and every violation is listed with its location in the document and the rule it broke. Honesty is a feature here: keywords outside the supported subset are named in a warning — this validator never lets an unchecked rule masquerade as a passed one.
Worked example
✖ INVALID — 4 violations:
/id — is below minimum 1
/email — is not a valid email
/plan — must be one of: "free", "pro", "team"
(document root) — required property "name" is missingWhat is checked
- Types (with the integer/number distinction), enum and const
- required, properties, additionalProperties, min/maxProperties
- String constraints: minLength, maxLength, pattern, common formats (email, date-time, uuid, uri, ipv4, hostname)
- Numeric constraints and multipleOf; array constraints incl. uniqueItems and prefixItems
- allOf, anyOf, oneOf, not, and local $refs into $defs/definitions
Limitations to know
- External $refs are not fetched (no network requests by design) and are reported as unchecked.
- Advanced keywords like unevaluatedProperties and conditional if/then are outside the subset — always surfaced in the warning, never silently skipped.
Workflow
- No schema yet? Generate a starting point from real data with the JSON to JSON Schema converter, tighten it, then validate here. Generate fresh test payloads from it with the Example Generator.
How to use the JSON Schema Validator
- Paste the JSON document into the first panel and the JSON Schema into the second.
- Click "Validate against schema".
- Each violation is listed with its location in the document and the rule it broke.
- Fix data or schema and re-run — inputs stay in place.
Frequently asked questions
Which schema keywords are checked?
The working core of draft 2020-12: type (incl. unions), enum, const, required, properties, additionalProperties, items/prefixItems, array and string constraints, numeric constraints, common formats (email, date-time, uuid, uri, ipv4…), allOf/anyOf/oneOf/not and local $refs. Anything outside that subset is named in a warning rather than silently skipped — you always know what was not checked.
How is this different from the JSON Validator?
The JSON Validator checks syntax — is this parseable JSON at all. This tool checks CONTENT against your contract: right types, required fields present, values within constraints. Valid syntax with a missing required field passes there and fails here.
Why does integer vs number matter?
"type": "integer" accepts only whole numbers — 2 passes, 2.5 fails. "number" accepts both. APIs that promise integers should say integer, and this validator enforces the difference.
My schema uses $ref to another file — will it work?
Local refs (#/$defs/… and #/definitions/…) resolve fully. External URLs are not fetched — this tool makes no network requests by design — and are reported as unchecked.
