JSON Schema Validator: Validate JSON Against a Schema Free Online
Paste your JSON and your schema, and instantly see every validation error with its exact property path. Supports all major JSON Schema drafts. No sign up, no server, runs entirely in your browser.
A JSON Schema validator for every major draft, built as a recursive keyword checker
JSON Schema validation is really a tree walk performed twice at once: once through your data, once through your schema, checking both structures in lockstep. This tool implements that walk directly rather than compiling the schema into a faster validation function first, which is the tradeoff every simple validator makes in exchange for being easy to read and modify.
Validation runs entirely in your browser. No JSON document or schema is transmitted anywhere, since the script contains no network calls at all.
Keyword coverage, from Draft 04 to 2020-12
The validator implements the keyword set most commonly used from JSON Schema Draft-07: type, required, properties, patternProperties, additionalProperties, minimum and maximum with their exclusive variants, multipleOf, minLength, maxLength, pattern, a handful of format checks, minItems, maxItems, uniqueItems, items, contains, minProperties, maxProperties, dependencies, the combiners allOf, anyOf, oneOf and not, conditional if/then/else, and internal $ref resolution against the local document. It also handles the newer keywords: $defs, $anchor, prefixItems, const, propertyNames, dependentRequired, dependentSchemas, minContains, maxContains, unevaluatedProperties and unevaluatedItems, plus boolean schemas. The draft selector, or the $schema in your schema, decides how draft specific keywords behave. On the official JSON Schema test suite it passes about 97 percent of cases; the misses are remote and dynamic references.
$ref pointing inside the document, by JSON Pointer, $id or $anchor, the validator walks the pointer path segment by segment against the root schema, decoding ~1 and ~0 per the JSON Pointer spec, then recurses into the resolved schema instead.
How errors are reported
Every failure becomes an object with a JSON Pointer style path built by appending /key or /index as the validator descends, the failing keyword name, and a human-readable message. Combiner failures inside allOf are additionally prefixed with the branch index, like [allOf/2] Minimum length 3, got 1, so you can trace a nested failure back to the exact sub-schema that rejected it.
| Format keyword | Pattern used |
|---|---|
Basic [email protected] shape. The local part can be plain or in double quotes, and a dot cannot start it, end it or repeat. The domain is a host name or an IP literal like [127.0.0.1]. Not the full RFC 5322 grammar | |
| date | YYYY-MM-DD with a real calendar check, so 2023-02-30 fails |
| date-time | Full RFC 3339 date and time with a time zone, like 2024-01-01T10:00:00Z |
| uuid | Standard eight-four-four-four-twelve hex grouping, case-insensitive |
| ipv4 | Four dot-separated numbers from 0 to 255 |
| ipv6 | Full IPv6 grammar, including :: compression and embedded IPv4 |
format as an annotation, not a hard constraint, so implementations may skip it. This tool checks formats by default because that is what most people want, and it now does so properly: 999.999.999.999 fails ipv4 and 2023-02-30 fails date. Untick Check formats to validate structure only. Unknown format names are listed but never fail.Two keywords that trip people up
additionalProperties: false
Every key in the data is checked against the declared properties list and any patternProperties regex. A key matching neither is flagged. This is the strict mode people reach for when they want to catch typos in field names rather than silently accepting them.
uniqueItems
Implemented as a nested loop doing a deep structural comparison between every pair of array elements, which correctly treats two objects with identical keys and values as duplicates even if they are different object references.
Schema specifications and validators
- JSON Schema Draft-07 release notes describe the keyword set this tool targets.
- RFC 6901, JSON Pointer defines the
#/path/to/valuesyntax used for both$refresolution and error paths. - Ajv is the industry standard JSON Schema validator for Node and the browser, supporting Draft-07 through 2020-12 with a compiled validation function for real performance.
- Understanding JSON Schema is the community reference guide for writing schemas correctly.
Validation work this covers
Checking an API response body against a documented contract before writing client code, validating a configuration file against its schema before a deploy, writing and iterating on a schema definition with instant feedback, and catching malformed data during onboarding of a third party feed before it reaches a database.
Questions About the JSON Schema Validator
JSON Schema is a vocabulary that lets you annotate and validate JSON documents. It defines the structure of valid JSON, which fields are required, what types values must be, what patterns strings must match, and what numeric ranges are acceptable. It is widely used in REST APIs (OpenAPI/Swagger), configuration file validation, database document validation, and data pipelines.
Draft 04, 06, 07, 2019-09 and 2020-12. Pick a draft or leave Auto detect on and the tool reads the $schema keyword. Draft specific rules are applied, such as boolean exclusiveMinimum in Draft 04, prefixItems in 2020-12 and unevaluatedProperties from 2019-09. Dynamic references ($dynamicRef, $recursiveRef) are treated as plain references.
The error path uses JSON Pointer notation (RFC 6901). A path like #/address/postcode means the error is at root → address property → postcode property. For arrays, #/items/2/name points to the name field of the third item (index 2). The path lets you locate the exact field that violated the schema without scanning the entire document.
Yes. References inside the same schema are resolved, whether they use a JSON Pointer such as #/definitions/Address or #/$defs/Address, an $id or an $anchor. A reference that cannot be resolved is reported as an error instead of being skipped. External $ref URIs pointing to remote schemas are not fetched, since this tool runs offline in your browser. For external references, inline the referenced schema into the $defs or definitions section of your schema.
email, date, time, date-time, duration, uri, uri-reference, iri, uuid, ipv4, ipv6, hostname, json-pointer, relative-json-pointer and regex. Dates are checked against the real calendar and IP addresses against valid ranges. Format checks are on by default and count as errors. Untick Check formats if you only want structural validation.
Use the items keyword in your schema: {"type":"array","items":{"type":"object","required":["id"],"properties":{"id":{"type":"integer"}}}}. Every element in the array is validated against the items schema, and each error is reported with its array index in the path, like #/2/id for a missing id on the third element.
No. The entire validation engine runs in your browser as JavaScript. Your JSON document and schema never leave your machine. This makes the tool safe to use with internal API payloads, configuration files containing credentials, or any sensitive data you would not want to upload to a third party server.
Yes. OpenAPI 3.x schemas are JSON Schema Draft-07 compatible. Extract the schema object from your API spec (the content → schema block for a given request or response), paste it here, and validate sample payloads against it. This is a fast way to test that a request body is correct before building a full integration test suite.
From the blog
Deep dives on the things these tools touch
Minification, UUID collisions, diffing API responses, and the other questions that come up around this toolset.
