JSON
JSON Schema Validator
Validate JSON data against a JSON Schema (draft-07 style) — with an exact path and explanation for every violation.
JSON Schema describes the expected structure of a JSON document — which fields are required, what type they are, and what constraints apply to their values. This tool checks actual data against a schema and shows the exact path to every violation.
How to use it
- Paste a JSON Schema into one field and the data to validate into the other.
- The result lists each violation separately: the exact path to the problem field and a plain-language explanation of why it doesn't match the schema.
- Valid data is immediately flagged as fully compliant with the schema.
Common uses
- Checking a third-party API response against its documented schema before integrating with it.
- Debugging your own JSON Schema — figuring out why seemingly valid data gets rejected.
- Validating a configuration file against a schema before deploying.
Things to keep in mind
JSON Schema has several versions (draft-07, 2019-09, 2020-12) with small syntax differences — check which version your production validator actually expects.
required only checks that a field is present, not its value — an empty string or null still counts as "present" if the type allows it.
Article about this tool: JSON Schema: describing and validating JSON structure
Frequently asked questions
What does a validation error mean?
It means the value at the reported path breaks a rule defined in the schema: wrong type, a missing required property, a pattern mismatch, or a value outside the allowed range. Each error comes with an exact path and explanation.
Which JSON Schema version does this tool support?
Validation targets draft-07 style — the most common set of keywords (type, required, properties, pattern, minimum/maximum, enum, and so on).
Is it safe to validate production data here?
Yes, both the schema and the data are processed entirely in your browser via JavaScript, with nothing sent to a server.
What does additionalProperties: false do?
By default an object can contain any fields beyond the ones described in properties. additionalProperties: false forbids extra fields — useful for catching a typo in a key name or a stray debug field left in by accident.
Can a field be described as allowing more than one type?
Yes, with an array in type — for example, "type": ["string", "null"] if a field can be a string or null. For more complex cases, use the oneOf, anyOf, or allOf keywords.