A schema describes the shape a document is supposed to have: which fields are required, what type each one is, which values are permitted. Validating against it catches the class of bug that syntax checking never will, where a payload parses cleanly and then fails somewhere that has no idea why.
This is usually the right tool when an integration is rejecting your request and the JSON itself looks fine. Draft 2020-12 changed several keywords in ways that fail quietly rather than loudly — `items` no longer does what it did for tuples — so a schema written years ago can validate everything and mean nothing.
Frequently asked questions
How is this different from the JSON Validator?
The JSON Validator answers "is this parseable JSON?" — a syntax question with one right answer. This answers "does this JSON match the shape my application expects?", which needs a schema to compare against. A payload can be perfectly valid JSON and still be missing every field your endpoint requires, and that is the failure this catches.
Which draft is supported?
Draft 2020-12, the current one. The full validation vocabulary is implemented: every type and constraint, enum and const, allOf/anyOf/oneOf/not, if/then/else, prefixItems and contains, dependentRequired and dependentSchemas, propertyNames and patternProperties, and unevaluatedProperties/unevaluatedItems. If you paste a draft-07 schema it still runs, and you get a warning about the two keywords that changed meaning rather than a silently different answer.
Why does my "pattern" match more than I expected?
Because JSON Schema patterns are searches, not full matches. "pattern": "abc" accepts "xxabcxx", since the regex only has to match somewhere in the string. Anchor it with ^ and $ if you mean the whole value — this catches out nearly everyone once, and it is a common source of validation that passes input it should reject.
Are remote $refs fetched?
No. Local references resolve — "#/$defs/address", "#/definitions/address" and "#" for the root all work — but nothing is downloaded, because this tool makes no network requests at all. An unresolvable reference is reported as an error rather than skipped, since a validator that quietly ignored part of your schema would tell you a document passed checks that never ran.
Why does it report every error instead of stopping at the first?
Because fixing a payload one error per run is a bad way to spend an afternoon. Every failure is listed with a JSON Pointer into the document — /users/2/email rather than "somewhere in users" — so a nested array of records tells you exactly which record and which field. The pointer syntax is RFC 6901, the same addressing every other JSON tool uses.
Should "format": "email" reject bad addresses?
By the specification, no: format is an annotation, and validators are not required to assert it. In practice almost everyone expects it to assert, so it is switched on here by default and you can turn it off to get spec-exact behaviour. The email check is structural rather than full RFC 5322 — the real grammar accepts addresses no mail server will deliver to, so a pragmatic check is the more useful one.
Is my data uploaded anywhere?
No. Validation runs entirely in your browser, which matters here more than for most tools — the documents people validate are usually real API payloads, and those tend to carry customer records, tokens or internal identifiers. Nothing is transmitted or stored.