/

JSON Schema Validator

Processed Client Side

Validate a JSON payload against a JSON Schema (draft-07 subset) and get precise, path-level error messages.

Schema · Data
JSON SchemaLength: 466Lines: 16Size: 466 BytesCursor: 1:1
JSON DataLength: 111Lines: 7Size: 111 BytesCursor: 1:1
Validation result
Paste a schema and data, then press Validate.

Bookmark this tool now — skip the search next time you need it.

About JSON Schema Validator

This tool runs entirely in your browser. Whatever you paste is processed on your own device and is never uploaded, logged, or sent to any server.

The JSON Schema Validator checks a JSON document against a JSON Schema and reports every rule it breaks, each with the path to the exact property at fault. It is the tool for the question "why is the API rejecting my payload?" — instead of one error at a time from a server, you get the full list at once: missing required properties, wrong types, values outside their range, strings that fail a pattern or format, and array items that do not fit. Schema and data go in two panes side by side, and the validator implements the draft-07 keyword set that real-world schemas are built from.

Key features

  • Every error reported at once, each with a property path such as user.roles[2] and a plain-language message
  • Type checking including union types and a genuine integer/number distinction
  • String rules: minLength, maxLength, pattern, and format for email, uri, date-time, date, time, ipv4, and uuid
  • Number rules: minimum, maximum, exclusiveMinimum, exclusiveMaximum, and multipleOf
  • Array rules: minItems, maxItems, uniqueItems, a single items schema, and positional tuple validation
  • Object rules: required, properties, patternProperties, additionalProperties, minProperties, and maxProperties
  • The combinators allOf, anyOf, oneOf, and not, with oneOf reporting how many branches actually matched
  • enum and const equality checks that compare nested structures, not just primitives
  • Copy the whole error list as text, and a clear Valid badge when the document passes

How to use it

  1. Paste your JSON Schema into the schema pane.
  2. Paste the document you want to check into the data pane.
  3. Press Validate.
  4. Work down the error list — each entry names the path and the rule that failed.
  5. Fix the data (or the schema), press Validate again, and repeat until you see the Valid badge.

Tips & common mistakes

  • Read the paths before the messages. Three errors under the same path usually mean one wrong value, not three separate problems.
  • A missing required property and a property set to null are different failures. required only checks that the key is present — allowing null needs "type": ["string", "null"] as well.
  • $ref is not resolved here, so schemas split across files or leaning on $defs need inlining first. Most schemas small enough to debug by hand are already self-contained.
  • format checks are pragmatic pattern matches, not full RFC parsers. They catch the everyday mistakes — a missing @, a date written the American way round — but a string that passes is not formally guaranteed valid.
  • additionalProperties: false is the keyword that most often surprises people. It rejects any key you did not declare, which is exactly what OpenAI-style strict structured output requires and exactly what breaks a payload carrying one extra field.
  • oneOf means exactly one branch must match. When it reports that two matched, the branches overlap — that is a schema bug, and anyOf is usually what was intended.
  • This validates a document against a schema. To check that JSON is syntactically well-formed in the first place, the JSON Validator is the faster route.

Related tools

Browse all 24 JSON tools

Frequently asked questions

10

Paste your JSON Schema into the left pane, the document you want to check into the right pane, and press Validate. Every rule that fails is listed with the path to the property at fault.

A draft-07 keyword subset covering what real-world schemas use: types, enum and const, string and number constraints, array and object rules, and the allOf, anyOf, oneOf, and not combinators.

All of them at once. That is the main advantage over discovering problems one at a time from an API that rejects your payload and only tells you about the first thing it disliked.

No. Schemas that split definitions across files or lean on $defs need inlining first. Most schemas small enough to debug interactively are already self-contained.

email, uri, date-time, date, time, ipv4, and uuid. These are pragmatic pattern checks that catch everyday mistakes rather than full RFC parsers, so passing is not a formal guarantee.

Because null is its own type in JSON Schema. Listing a property in required only demands that the key exists — to allow null you also need a union type such as ["string", "null"].

The schema sets additionalProperties to false, so any key it does not declare is rejected. It is a common cause of failures when a payload carries one extra field the schema was never told about.

oneOf requires exactly one branch to match. If two do, the branches overlap and the schema needs tightening — or anyOf was what you actually meant.

No. Validation runs entirely in your browser, so API payloads and internal schemas stay on your machine.

The JSON Validator checks that a document is syntactically valid JSON. This tool assumes it already is and checks whether it satisfies the rules of a schema.