Validate a document against a schema, and see exactly what broke
A validator that says "invalid" is halfway to useless. This one reports every violation with the path, the rule that was broken, what the schema expected and what the document actually contained.
- Draft
- 2020-12
- Output
- Path-level errors
- Server
- None
How to use it
- Paste the schema A draft 2020-12 schema. It can be a full schema with $ref, or a fragment with just type and properties.
- Paste the document The instance you want to check. It does not have to be pretty-printed.
- Read the violations Each failure is listed with its path, the keyword that failed, the expected value and the actual one.
Reference
The errors this reports
| Keyword | Meaning |
|---|---|
| `type` | The value is not of the declared type |
| `required` | A required property is missing |
| `enum` | The value is not one of the allowed values |
| `minimum` / `maximum` | The number is out of range |
| `minLength` / `maxLength` | The string is the wrong length |
| `pattern` | The string does not match the regular expression |
| `additionalProperties` | An unexpected property is present |
Questions people ask
Which JSON Schema draft is supported?
Draft 2020-12, which is the current recommendation. Most older schemas in the wild also work, since the core keywords have not changed.
Why is my $ref not resolving?
A reference to another file would need to be fetched over the network, and the tool makes no network requests. Inline the referenced fragment into the schema, or use a self-contained schema.
Does it validate the schema as well?
No. It validates the document against the schema. Whether the schema itself is sensible is a separate question, and a permissive schema will pass anything.
What does "invalid" mean exactly?
That at least one keyword was violated. The list names each one with the path of the offending value, so you get the location and the reason rather than a boolean.
Can it validate a whole folder of files?
Not in the browser. This tool handles one document at a time, which suits the common case of checking a payload or a fixture.
Is the document uploaded?
No. Validation runs in the browser. The document being validated is frequently a customer record or an internal API response, which is exactly the kind of thing that should not be pasted into a form.
Details that catch people out
This validates an instance against a schema. It does not check the schema itself — a schema that says everything is optional will pass anything. If you need the schema to be well-formed, that is a different check.
A schema that uses $ref to another file cannot be resolved here, because resolving it would mean fetching a remote document, and the tool does not make network requests. Inline the referenced part, or paste the referenced schema into the document pane.
Where this earns its keep
Checking a webhook payload
A provider publishes a schema for the payload it sends. Paste one real delivery and find out immediately whether it conforms.
Debugging a form submission
The client says the form is invalid and the server does not say why. Validating against the schema locally shows which field is wrong.
Contract testing in a pull request
Validating a fixture against the schema catches a breaking change to the contract before it reaches a consumer.
A schema is often a public document
The schema for a webhook is published, so the schema is not the secret. The instance is. Validating locally means the payload being checked never leaves your machine, which is the only acceptable way to handle a customer record or an internal response.
- Validation runs in the browser against draft 2020-12.
- Every violation is reported with its path and the rule that failed.
- No network requests, so a $ref to a remote document is the only limitation.
- The document being validated is never transmitted.
Last reviewed 2026-10-16. Every tool on DevSnap runs entirely in your browser, so whatever you paste here never reaches a server.