Answer: The JSON Schema Validator produces your output instantly from the input you provide — everything runs in your browser, free, with no signup required.
Check a JSON document against a schema, with exact error locations
Quick answer: JSON Schema validation compares your document to a contract of type, required, properties, minimum, pattern and similar keywords, then reports every violation with a JSON-pointer path. Paste your schema on the left, the document on the right, and hit Validate. Nothing leaves your browser.
| draft-07 | 2019-09 | 2020-12 | |
|---|---|---|---|
| $schema URI | http://json-schema.org/draft-07/schema# | https://json-schema.org/draft/2019-09/schema | https://json-schema.org/draft/2020-12/schema |
| Reusable definitions | definitions | $defs | $defs |
| $ref siblings | Ignored ($ref overrides) | Applied alongside $ref | Applied alongside $ref |
| Tuples (fixed positions) | Array-form items + additionalItems | Array-form items + additionalItems | prefixItems + items (replaces both) |
exclusiveMinimum | Number, e.g. 18 | Number | Number (same as -07) |
| Where you'll meet it | Most APIs, OpenAPI 3.0, Swagger | Transitional; some tooling | OpenAPI 3.1, modern tooling |
The biggest practical jump is OpenAPI 3.0 → 3.1: 3.0 is built on draft-07, 3.1 on 2020-12, so schemas written for one can misbehave under the other. Picking the dialect here matches what each specification expects.
These are the exact messages Ajv 8.17.1 (the engine on this page) prints for each failing keyword. The path in front of each message tells you where; this table tells you what to change.
| Keyword | Ajv error message | Typical fix |
|---|---|---|
required | must have required property 'email' | Add the missing field, or drop it from the required array if it's really optional. |
type | must be integer | Send the right JSON type. "5" is a string, not a number; strip the quotes or change the schema. |
additionalProperties | must NOT have additional properties (shown here with the offending name) | Remove or rename the stray key, or declare it under properties. |
minimum | must be >= 18 | Raise the value, or lower the limit if the rule is wrong. Use exclusiveMinimum for strict >. |
enum | must be equal to one of the allowed values | Check spelling and case; enum matching is exact, so "Red" won't match "red". |
pattern | must match pattern "^[A-Z]{3}$" | Fix the value, or anchor the regex with ^ and $ if it's matching too loosely. |
format | must match format "email" | Correct the value. On this page format is checked for email, date, date-time, uri and uuid. |
minLength | must NOT have fewer than 1 characters | Usually an empty string "" slipped through a form. Fill it or omit the key. |
maxItems | must NOT have more than 2 items | Trim the array, or raise the limit if the cap was a guess. |
uniqueItems | must NOT have duplicate items (items ## 0 and 2 are identical) | Dedupe the array. The indexes point at the two matching entries. |
oneOf | must match exactly one schema in oneOf | The value matched zero branches or more than one. If branches overlap, switch to anyOf or make them mutually exclusive. |
const | must be equal to constant | Send the one allowed value exactly, e.g. a "version": "v1" discriminator. |
With every error reported at once, a failed oneOf also lists each branch's own failure (say, must be string and must be boolean) above the oneOf line. Read the branch errors first; they usually say which branch you meant to hit and why it missed.
A JSON Schema is a machine-readable contract: it states what a valid document must look like, and a validator answers the yes/no question, with reasons. This page runs Ajv (the same library that guards countless Node.js APIs) compiled for the browser, so results match what your production code would say.
First the schema itself is parsed and checked against its dialect's meta-schema, catching typos like reqired before they produce nonsense verdicts. Then the schema compiles into a validation function, and that function runs against your document. Each failed keyword produces an error carrying an instancePath (where in the document), a message (what went wrong), and params (the specific keyword values involved).
Paste the schema on the left and the document on the right. Choose a dialect or leave it on auto: auto reads your $schema declaration and falls back to draft-07 when there isn't one, matching Ajv's default. Hit Validate for a pass/fail verdict and, on failure, one line per problem with its pointer path.
Load the sample. The schema requires name and email, allows only those three properties (additionalProperties: false), and demands age be an integer of at least 18. The sample document ships three violations, and the validator reports exactly these:
/ must have required property 'email'/ must NOT have additional properties (nickname)/age must be >= 18 (the document says 17)Fix all three and the verdict flips to green. That pointer-first style is the point: instead of "validation failed", you get the branch of the document to walk to find each problem.
This one catches almost everybody who tries to extend a base schema. additionalProperties only sees properties declared in the same subschema, so a property that lives inside an allOf branch counts as "additional" and gets rejected. Run {"allOf":[{"properties":{"a":{}}}],"properties":{"b":{}},"additionalProperties":false} against {"a":1,"b":2} and Ajv answers must NOT have additional properties for a. In 2019-09 and 2020-12, use unevaluatedProperties: false instead; it can see properties that were evaluated by subschemas. On draft-07 the only fix is to redeclare those properties in the outer schema.
Draft-03 let you write "required": true on a property. Since draft-04, required is an array of names that sits on the object, next to properties. Put "required": true inside a property and the schema fails its meta-schema check (must be array). Put an array there and it's worse: the schema is valid, but it only applies if that property's value is itself an object, so nothing is enforced and you won't get a warning.
Since draft-06, "type": "integer" means any number with a zero fractional part, so 1.0 passes and 1.5 fails. If you really need to rule out a decimal point in the raw text, a schema can't do it, because JSON parsers treat 1.0 and 1 as the same number before the validator ever sees them.
In 2019-09 and 2020-12, format is an annotation by default. Plenty of validators will happily accept "not-an-email" for "format": "email" unless you switch on format assertion. This page does check the common formats, but don't assume your server-side validator does the same. Test it with a bad value before you rely on it.
Paste your schema into the first box and the document you're testing into the second, then hit Validate. The validator checks the document against every applicable keyword (type, required, properties, minimum, pattern and so on) and reports each violation with its exact location, like /age must be >= 18. If the schema itself is malformed, you get a schema error instead.
Draft-07, 2019-09, and 2020-12, the three dialects you'll meet in practice. The tool reads your $schema declaration and picks the matching engine automatically; if there's no $schema, it assumes draft-07, which is still the most widely deployed dialect in APIs and configs.
No. Parsing and validation happen entirely in your browser with Ajv compiled to JavaScript. Nothing is uploaded, logged, or stored, which is why the page works even for payloads you couldn't paste into a shared paste-bin.
instancePath is a JSON Pointer to the exact spot that failed: an empty path means the document root, /items/2/price points at the price field of the third array item. Read it right-to-left as a breadcrumb from your document to the failing value.
In JSON Schema, format is annotation-only by default, so many validators skip it unless configured for assertions. This validator enables format checking for the common ones (email, date, date-time, uri, uuid) so bad values are caught, and rejects schemas that use formats it doesn't know about rather than silently ignoring them.
Not directly here, since the validator expects JSON. Convert first: our YAML validator converts YAML to JSON, and most pipelines keep a JSON export step anyway. The schema itself must be JSON as well, though $ref can point at YAML files in other tools.
Syntax validation only asks whether the text is legal JSON: matched braces, quoted keys, no trailing commas. Schema validation starts after that and asks whether the parsed data has the right shape, such as required fields, types, ranges and allowed values. A document can be perfectly valid JSON and still fail its schema. This tool does both, and tells you which one failed.
Because additionalProperties only looks at properties and patternProperties in its own subschema. It can't see into allOf branches, so anything declared there counts as extra. In 2019-09 or 2020-12, swap it for unevaluatedProperties: false, which does see properties validated by subschemas. On draft-07, redeclare the inherited properties next to additionalProperties.