How JSON Schema Validation Works
Paste a JSON document and a schema, then inspect validation errors. Schema validation goes beyond parsing by checking the structure and constraints declared in the schema. Keep schema and sample data separate so each can be reviewed.
JSON Schema Draft-07 Basics
Draft-07 uses keywords such as type, properties, required and items. Declare the draft to make the intended vocabulary clear. A schema without a required list does not automatically require every property it describes.
Required Fields, Types and Constraints
Required fields control presence; type controls the value kind; bounds and length constraints restrict allowed values. Use additionalProperties deliberately. Test both valid and invalid examples so an accidentally permissive schema does not go unnoticed.
Generating a Schema From Sample JSON
Generate mode infers a starter schema from sample values. It cannot know all optional fields or future variants. Review required fields, empty arrays, nulls and ranges before treating inferred output as a production contract.
Reading Validation Errors
Errors identify paths and failed constraints. Fix the schema if it expresses the wrong requirement; fix the data if the contract is correct. Remote schema references are not fetched, keeping input processing local.
More examples and technical details
What JSON Schema Actually Checks
A JSON parser tells you whether a document is syntactically valid JSON. That is a low bar: a missing comma fails, and absolutely everything else passes. JSON Schema is the layer above, describing what a valid document means for your application rather than for the parser.
A schema is itself a JSON document, which is the design decision that makes the whole thing practical. Schemas can be stored, versioned, diffed, transmitted over an API, and validated by other schemas, all with tooling you already have. There is no separate grammar to learn, only a vocabulary of keywords.
The keywords are assertions about a value. Applied to an instance they produce a pass or a fail, and on failure a validator reports which part of the document broke which rule, expressed as a JSON Pointer path.
Draft Versions
| Draft | Status | What changed |
|---|---|---|
| draft-04 | Legacy | required as an array, exclusiveMinimum as a boolean |
| draft-06 | Superseded | Introduced const, contains, propertyNames |
| draft-07 | The practical baseline | if / then / else, readOnly, content keywords |
| 2019-09 | Adopted slowly | $defs replaces definitions, $recursiveRef, annotations |
| 2020-12 | Current | prefixItems for tuples, $dynamicRef, unevaluatedProperties |
Draft-07 remains the version with the broadest library support across languages, and it is the safe default unless you specifically need something newer. The most visible difference for anyone moving forward is tuple validation: draft-07 uses an array value for items, while 2020-12 uses prefixItems and reserves items for the rest of the array. Declare your draft in the $schema keyword so validators know which rules to apply rather than guessing.
Core Keywords
| Keyword | Applies to | Meaning |
|---|---|---|
| type | Any | Restricts to string, number, integer, boolean, object, array, or null |
| properties | Object | Declares a subschema for each named key |
| required | Object | An array of key names that must be present |
| additionalProperties | Object | false forbids unlisted keys, or give a subschema they must match |
| items | Array | The subschema every element must satisfy |
| minItems / maxItems | Array | Bounds on length |
| uniqueItems | Array | true rejects duplicate elements |
| enum | Any | The value must be one of an explicit list |
| const | Any | The value must equal exactly one thing |
| minimum / maximum | Number | Inclusive bounds, with exclusive variants available |
| multipleOf | Number | Divisibility, useful for currency steps |
| minLength / maxLength | String | Bounds counted in characters, not bytes |
| pattern | String | A regular expression the value must match |
| format | String | Named formats such as email, uri, date-time, uuid |
| oneOf | Any | Must match exactly one of the listed subschemas |
| anyOf | Any | Must match at least one |
| allOf | Any | Must match every one, used for composition |
| not | Any | Must fail the given subschema |
| $ref | Any | Reuse a subschema defined elsewhere, including recursively |
| $defs | Schema | Where reusable subschemas live, called definitions before 2019-09 |
One trap worth naming: required and properties are independent. Listing a key under properties does not make it mandatory, and a key can be listed in required without appearing in properties at all. Forgetting required is the single most common reason a schema passes documents it should reject.
A Worked Example
The schema
Valid document
Invalid document
Errors reported for the invalid document
Three separate failures, each with a pointer to the offending location and the keyword that rejected it. A validator reports all of them at once rather than stopping at the first, which is what makes schema errors usable as form validation messages.
Where Schemas Get Used
- API request validation. Reject a malformed body at the edge with a precise error instead of letting it reach business logic and fail obscurely.
- Configuration validation. Catch a typo in a config file at startup with a clear message rather than at three in the morning when a feature silently misbehaves.
- OpenAPI specifications. The components section of an OpenAPI document is JSON Schema, so learning one teaches you most of the other.
- Form generation. Libraries render a working form directly from a schema, so the validation rules and the UI cannot drift apart.
- Editor autocomplete. Add a $schema key to a config file and editors offer completion, inline documentation, and red squiggles while you type.
- Test fixtures and contract testing. Assert that a recorded response still matches the agreed shape after a dependency changes.
- Documentation. A schema with description and examples keywords is machine readable documentation that cannot go stale.
Schemas Versus TypeScript Types
They look like they do the same job and they operate at opposite ends of the program lifecycle.
| TypeScript type | JSON Schema | |
|---|---|---|
| Checked at | Compile time | Run time |
| Exists in the shipped code | No, erased entirely | Yes, it is data |
| Validates untrusted input | No | Yes, that is the point |
| Value constraints | Only literal unions | Ranges, patterns, lengths, uniqueness |
| Error messages | Compiler diagnostics for you | Structured errors you can return to a caller |
| Shareable across languages | No | Yes, any language with a validator |
| Cost | Free at run time | A real validation pass per document |
A type asserts that a value has a shape. A schema checks it. Casting a fetch response with as tells the compiler to stop asking questions and does absolutely nothing to the bytes that arrived. If the API changed last night, your typed code walks straight into undefined.
The two are complements rather than competitors. Use types everywhere inside your own code, where you control both sides, and validate with a schema at every trust boundary: HTTP requests, webhook payloads, uploaded files, message queue events, and configuration read from disk. Tools exist to generate types from a schema so the two never disagree, which gives you one source of truth and both kinds of checking.
Validation fits alongside the other ways of pinning down a payload. Browse the full converter collection for JSON to TypeScript to get compile time types from the same sample, JSON to GraphQL for a schema that also defines an API surface, and JSON Formatter to tidy a document before you validate it.
Standards and references
Frequently asked questions
What is JSON Schema validation?
It checks a JSON value against a declared structure and constraints.
How is it different from JSON syntax validation?
Syntax validation checks grammar only. Schema validation can require fields and enforce their types or ranges.
Which JSON Schema draft is supported?
The validator supports draft-07 constraints. Format annotations are not asserted, and remote references are not downloaded; include referenced definitions in the schema.
Can the tool generate a schema from JSON?
Yes. Generate mode creates a starting schema that needs review against your intended contract.
Is data uploaded?
No. Input is processed in this browser tab and is not uploaded by the tool. Copy and download are actions you control; ordinary page analytics do not receive tool input.