JSON Schema Validator — Online JSON Schema Tester
🔒 Runs in your browser — nothing is sent to a serverJSON Schema validator that runs entirely in your browser. Paste a JSON Schema on the left, the data document on the right, pick a draft (2020-12, 2019-09, draft-07, draft-06 or draft-04) and the validator reports `valid` or every failing rule with a JSON Pointer to the offending field, the schema path that triggered the error, and a human-readable message. Powered by AJV, the de-facto JavaScript reference implementation. Everything runs 100% inside your browser; the schema and data never leave your device, nothing is uploaded, logged or sent to any server. External `$ref` URLs are deliberately not fetched.
External $ref URLs are not fetched (privacy). Use inline$defs for shared subschemas.
Why validate JSON against a schema in the browser
Schema validation is normally part of a server-side build or an API gateway, and the feedback loop is slow — change the contract, deploy, see the failure in a log, repeat. A live in-browser JSON Schema validator collapses that loop into seconds: paste the schema, paste a payload, click Validate, read the JSON Pointer to the broken field. It is also far safer than online schema checkers that POST your data to a server you do not control. AJV runs as plain JavaScript here, so the schema, the data and the result stay on your machine. Use it during contract negotiation between front-end and back-end teams, while reviewing OpenAPI spec changes, or to debug the exact moment a webhook payload starts failing in staging.
How AJV reports errors and how to read them
AJV walks the schema and the data in parallel and emits one `ErrorObject` per failed rule. Each error has `instancePath` (a JSON Pointer to the location in the data), `schemaPath` (an internal pointer into the schema), `keyword` (the rule that failed — `required`, `type`, `pattern`, `minLength`), `params` (rule-specific context, such as the missing key for `required`) and `message` (a human-readable explanation). The validator on this page surfaces the path and the message; reading the schema path is helpful when the same constraint appears in multiple sub-schemas, because it tells you which branch produced the failure.
Examples
{"type":"object","required":["id","email"],"properties":{"id":{"type":"integer"},"email":{"type":"string","format":"email"}}}Valid against {"id": 7, "email": "ana@example.com"}{"type":"object","properties":{"a":{"type":"string"}},"additionalProperties":false}Invalid: /b — must NOT have additional properties{"type":"string","pattern":"^[A-Z]{3}-\\d{4}$"}Invalid: (root) — must match pattern "^[A-Z]{3}-\\d{4}$" (got "abc-1234"){"type":"array","items":{"type":"string"},"uniqueItems":true}Invalid: /1 — must NOT have duplicate items (items ## 0 and 1 are identical)