The share link contains your schema — share it only where you'd share the schema itself.
About the JSON Schema validator
JSON Schema is a vocabulary for describing the shape of JSON data — which properties an object may have, which are required, what types and formats each value should take, and how arrays and nested objects are structured. This tool validates the schema document itself: it confirms that your schema is well-formed and conforms to the JSON Schema specification you're targeting. That is distinct from data validation — checking a particular JSON payload against a schema — which is a separate step on the Phase 2 roadmap.
The validator supports Draft 7, Draft 2019-09 and Draft 2020-12. Which draft applies is decided automatically from the $schema keyword at the root of your document. When you declare, for example, "$schema": "https://json-schema.org/draft/2020-12/schema", the tool checks your schema against that draft's meta-schema. If $schema is absent or unrecognized, it defaults to Draft 2020-12 — so the cleanest way to pin behavior is to set $schema explicitly.
format assertions are enabled, so declared formats such as date-time, email and uri are actually checked rather than ignored. Errors are reported against the JSON Pointer where they occur — for instance /properties/age — so you can jump straight to the offending keyword. Everything runs locally in your browser; nothing is uploaded.
Draft 7 vs 2020-12 keyword mapping
If you are migrating a schema, these are the keywords that moved or changed between Draft 7 and Draft 2020-12 (Draft 2019-09 introduced most of them):
How common JSON Schema keywords map from Draft 7 to Draft 2020-12.
| Purpose | Draft 7 | Draft 2020-12 |
|---|
| Tuple / positional array items | items (as an array) + additionalItems | prefixItems + items |
| Reusable subschemas | definitions | $defs |
| Property dependencies | dependencies | dependentRequired + dependentSchemas |
| Catch unmatched properties | additionalProperties only | additionalProperties + unevaluatedProperties |
| References with siblings | $ref overrides sibling keywords | $ref applies alongside siblings |
JSON Schema validation FAQ
What's the difference between Draft 7 and Draft 2020-12?
Draft 7 is the older, widely deployed revision; Draft 2020-12 is the current standard, with Draft 2019-09 the transitional release between them. The biggest changes are in how arrays and references work. For tuple-style arrays, Draft 7 used items (as an array) plus additionalItems, whereas 2020-12 uses prefixItems for the positional entries and items for the rest. Draft 2019-09 introduced $defs (replacing definitions), split the old dependencies keyword into dependentRequired and dependentSchemas, and added unevaluatedProperties; 2020-12 carried those forward and reworked $ref so it can sit alongside sibling keywords instead of overriding them. In practice, Draft 7 remains the safest choice for maximum library compatibility, while 2020-12 is preferred for new schemas that want the latest keywords. Pick the draft that matches your tooling, declare it with $schema, and the validator checks your document against that draft's own meta-schema.
Should I use JSON Schema or Avro?
JSON Schema constrains human-facing JSON documents; Avro is a compact binary format for data pipelines. For a full comparison of when to choose each, see the guide JSON Schema vs Avro at /guides/json-schema-vs-avro/.
How does $schema auto-detection work, and what's the default?
The validator reads the $schema field at the root of your document and selects the matching draft meta-schema. If $schema is missing or unrecognized, it falls back to Draft 2020-12, the current default. Adding an explicit $schema is the most reliable way to control which draft is applied.
Are Draft 3 and Draft 4 supported?
No. The validator targets Draft 7, Draft 2019-09 and Draft 2020-12. Draft 3 and Draft 4 are legacy revisions and are not supported; migrate older schemas to Draft 7 or later.
Does it enforce the format keyword?
Yes. format assertions are enabled, so values declared as date-time, email, uri and similar formats are checked rather than treated as annotations only.
Does it validate data against the schema?
Not yet. This page validates that the JSON Schema document itself is well-formed and conforms to the chosen draft. Validating a separate data instance against your schema is on the Phase 2 roadmap.