JSON Schema Validator
Paste a JSON Schema and a JSON document and see at once whether the data conforms. Each problem is explained in plain words, with the path to the value and a link to its line in the editor. Both documents stay in your browser.
- Runs in your browser
- No sign-up
- Free to use
How to use JSON Schema Validator
- Paste or open your JSON Schema on the left.
- Paste or open the JSON data on the right.
- Read the verdict; validation runs as you type, or press Validate.
- Select a problem in the list to jump to the line in the data.
JSON Schema Validator features
All errors at once
The full list of violations is reported, not just the first.
Plain-language messages
“Missing required property”, “Must be integer, but is string”, “Property is not allowed here”.
Jump to the line
Each problem is located in the data and can be selected to highlight its line.
Schema checked too
A schema that is itself malformed is reported before any data is validated.
Format checks
Optional validation of email, date, date-time, URI, IPv4, IPv6, UUID and other formats.
Honest about versions
Validates with draft-07 rules and tells you when a schema uses keywords from newer drafts that are not evaluated.
When to use JSON Schema Validator
- Checking an API request or response against its published schema.
- Testing a schema while writing it, with data that should pass and data that should fail.
- Finding out why a configuration file is rejected by a tool.
- Verifying webhook payloads or fixtures before using them in tests.
JSON Schema Validator FAQ
Which JSON Schema versions are supported?
Draft-07 and draft-06 fully. Schemas declaring draft 2019-09 or 2020-12 are checked with draft-07 rules: the common keywords behave the same, but keywords added later, such as prefixItems, unevaluatedProperties and dependentRequired, are not evaluated. The tool lists any such keywords it finds in your schema.
Are $ref references resolved?
References within the same schema, such as "#/definitions/address" or "#/$defs/address", are resolved. References to other files or URLs are not fetched, and are reported as unresolved.
Why does my data pass although the schema looks strict?
JSON Schema is permissive by default. Properties not mentioned in the schema are allowed unless additionalProperties is false, and keywords only apply to their own type: minLength is ignored for a number. Add "type" and "required" to make the intent explicit.
What is the difference between this and the JSON Validator?
The JSON Validator checks syntax: whether the text is well-formed JSON. This tool checks meaning: whether well-formed JSON has the structure, types and values that a schema demands.
Is format validation part of the standard?
Formats are defined by the standard, but validators may treat them as annotations only. Here format checking is on by default and can be switched off to match validators that ignore it.
Is my data sent to a server?
No. Validation is performed by a JavaScript library in your browser.
How JSON Schema validation works
A JSON Schema is a set of constraints. Each keyword in it adds one: type restricts the kind of value, required lists mandatory properties, minimum bounds a number, pattern tests a string. Validation means applying every constraint in the schema to the corresponding part of the data. The data is valid when none fails. Nested schemas under properties and items apply the same process one level down.
Two characteristics of the language surprise newcomers. First, constraints are independent and only apply where they are relevant. A schema with "minLength": 3 and no type accepts the number 7, because minLength concerns strings only. Second, anything not forbidden is allowed. An empty schema accepts every document, and an object may contain properties the schema never mentions unless additionalProperties says otherwise. A strict schema is therefore one that states type, required and additionalProperties explicitly.
Combining keywords add logic. allOf requires every listed sub-schema to pass, anyOf at least one, oneOf exactly one, and not inverts a schema. if, then and else make constraints conditional. With $ref, a schema can reuse definitions and even describe recursive structures such as trees. Error messages from combinators are harder to read, since a failure of anyOf is really a failure of each alternative; the list here shows the summary and the individual reasons.
The specification has evolved through several drafts. Draft-07 remains the most widely implemented. Drafts 2019-09 and 2020-12 reorganised the vocabulary, renamed definitions to $defs and added keywords for tuples and for properties not covered by any sub-schema. This validator implements draft-07. For schemas that depend on the newer keywords, validate with a 2020-12 implementation in your build pipeline; the notes under the verdict tell you when that applies.