Result appears here after you select
{ } How to use
- Paste the schema, then the document to check. A line of dashes between them is optional.
- Select Process.
- Each row is one broken rule, with a JSONPath to the value that broke it.
{ } How it works
JSON Schema Validator works on the text you provide. Select Process ▸ and it runs entirely in your browser — nothing is uploaded to a server — then shows the result in the Output panel.
Input
- Schema first, then the document — paste or type your input in the left panel (use Sample for an example)
Output
TXT text — copy or download it from the Output panel.
{ } Common uses
- Check an API response really matches the schema its documentation promises.
- Validate a config file before shipping it, rather than finding out at start-up.
- Test a schema you have just written against a document you know should fail.
- Find every problem at once instead of fixing them one error at a time.
{ } Limitations
- A useful subset of draft 7: types, required, properties, additionalProperties, patternProperties, items, enum, const, the numeric and length and count bounds, pattern, the common formats, and allOf/anyOf/oneOf/not.
- References are followed only inside the same document. A remote $ref cannot be fetched from a browser, and it is reported as a problem rather than skipped — a validator that quietly ignored a reference would pass documents it never checked.
- A format it does not know is reported as unchecked rather than passed. That is noisier and honest; the alternative is a green tick for a rule nobody applied.
{ } FAQ
Is my data uploaded to a server?
No. Everything runs locally in your browser — your files never leave your device.
Can I process more than one file at once?
This tool works on one input at a time.
Is this tool free?
Yes — it’s completely free and needs no sign-up.
Why does it complain about a format that looks fine?
If the message says the format is not checked here, it is telling you that rule was not applied — not that the value is wrong. Formats like "email" and "date-time" are checked; unusual or custom ones are not, and saying so is better than a tick that means nothing.
Why does it stop after a type error on one value?
Because every other rule on that value is about a type it does not have. A string where an object was expected would otherwise also fail "required", "properties" and everything else, burying the one problem that matters under its own consequences.
Is my schema or data uploaded?
No. Both are read in your browser and nothing is sent anywhere, which matters because a schema is often unreleased API design and the document beside it is often real data.