Skip to content
koducathome

JSON Schema Validator

Check a JSON document against a JSON Schema (draft 4, 7, 2019-09 or 2020-12) and see every violation with its path.

How to use this tool

Steps for using the JSON Schema Validator.

  1. Paste your JSON Schema into the JSON Schema editor and the document to check into the JSON data editor — validation runs as you type. Click Sample for an order schema with failing data, or Valid sample for data that passes.
  2. Leave Draft on Auto to use the draft declared by the schema's $schema (2020-12 if none), or pick 2020-12, 2019-09, 7 or 4 yourself.
  3. No schema yet? Paste example data and click Infer schema from data to generate a starting schema with types, required keys, array items and common string formats — then tighten it by hand.
  4. Read the violations: each shows the failing keyword, a message, the location in the data (such as #/items/0/qty) and the rule in the schema. Failing lines are highlighted in both editors; click the target icon to jump to one.
  5. Filter by keyword or search by path, optionally show the parent errors, and use Copy report to share the results.

Example

A missing required property and a value out of range

Schema and data
Schema: {"type":"object","required":["name","age"],"properties":{"age":{"type":"integer","minimum":0}}}
Data:   {"age": -3}
Errors (draft 2020-12)
#       required  Instance does not have required property "name".
#/age   minimum   -3 is less than 0.

Common use cases

  • Checking an API request or response body against its OpenAPI or JSON Schema contract while debugging.
  • Writing and testing a new schema against sample payloads before adding it to a CI pipeline.
  • Verifying that a configuration file matches the schema your application loads at startup.
  • Explaining to a teammate exactly which fields of a payload break the contract, with paths.
  • Comparing how the same schema behaves under different drafts when upgrading tooling.

How JSON Schema validation works

JSON Schema is a JSON document that describes what another JSON document must look like: which properties are required, what type each value has, allowed ranges, string patterns, array lengths and more. It is the contract language behind OpenAPI 3.1, many configuration formats and editor autocompletion. Validation answers a different question from a syntax check — the JSON Validator tells you whether text is JSON at all, while a schema tells you whether that JSON has the right shape.

Validation runs in your browser using the @cfworker/json-schema library with drafts 4, 7, 2019-09 and 2020-12. It runs in "collect all errors" mode instead of stopping at the first failure, so you see every violation in one pass. Each error has an instance location, a JSON Pointer into your data where # is the root and #/items/0/qty is the qty property of the first item, and a keyword location that points to the rule in the schema that failed.

Applicator keywords such as properties, items and allOf produce a parent error ("Property \"items\" does not match schema") in addition to the specific error underneath. Parent errors are hidden by default so the list focuses on what to fix, and you can show them to see the full chain. The tool also filters out a misleading duplicate that the library emits when a declared property fails and the schema sets additionalProperties.

The draft matters because keywords changed between versions. In draft 4, exclusiveMaximum is a boolean that modifies maximum; from draft 6 onward it is a number. Draft 2020-12 replaced array-form items with prefixItems and introduced $defs and unevaluatedProperties. Check the $schema URI at the top of your schema and pick the matching draft.

Limitations

  • Remote $ref URLs are never downloaded. Inline referenced schemas under $defs (or definitions in older drafts) and use local references such as #/$defs/address.
  • The format keyword is only partially enforced: date, time, date-time, duration, email, hostname, ipv4, ipv6, uri, uri-reference, uuid, regex and the JSON Pointer formats are checked; others such as idn-email and iri, and any custom format, are accepted without error.
  • The schema itself is not validated against the draft's meta-schema, so a misspelled keyword (such as requried) is silently ignored, as the specification requires.
  • Draft 2020-12 $dynamicRef / $dynamicAnchor and custom vocabularies are not supported. Each editor is limited to 2 million characters.

Frequently asked questions

Which JSON Schema drafts are supported?

Draft 4, draft 7, draft 2019-09 and draft 2020-12. Draft 6 schemas generally validate correctly with the draft 7 setting, since draft 7 only added keywords such as if/then/else.

Why does my schema accept data it should reject?

The most common causes are a misspelled keyword (unknown keywords are ignored), a missing "type": "object" together with required, additionalProperties not being set to false, or a format the validator does not check. Also make sure the selected draft matches the keywords you use.

What do the # paths mean?

They are JSON Pointers prefixed with #. # is the whole document, #/user/email is the email property inside user, and #/items/2 is the third array element. Characters / and ~ inside keys are escaped as ~1 and ~0.

Can I use $ref to another file or URL?

Only references within the same schema are resolved. Remote references produce an "Unresolved $ref" error; copy the referenced schema into $defs and point to it with #/$defs/name.

Can I generate TypeScript types from my data instead?

Yes — the JSON to TypeScript tool infers interfaces from sample JSON.

Is my schema or data uploaded?

No. Both are parsed and validated locally in your browser.