JSON Schema Validator
Validate JSON data against a JSON Schema
100% free. Runs entirely in your browser - your files and data never leave your device and nothing is uploaded to any server.
Enter a schema and JSON data above to see validation results.
About this tool
JSON on its own carries no rules. A field can be a string in one record and a number in the next, a required value can simply be absent, and nothing complains until something downstream breaks in a confusing way. JSON Schema adds those rules: this field must be a string, this one is required, this number must be positive, this array needs at least one item. Validating against it moves failures to the moment the data arrives rather than three systems later. The keywords doing most of the work are few - type, required, properties, and the constraints like minimum, maxLength and pattern. The one that surprises people is additionalProperties: by default a schema permits fields it never mentioned, so a payload with a misspelled key validates happily while the correctly spelled field is missing. Setting it to false is what turns a typo into an error. Validation runs in your browser.
How to use this tool
- Paste your schemaThe rules the data must satisfy - types, required fields and constraints.
- Paste the JSON dataA real payload rather than an idealised one. Edge cases are where schemas earn their keep.
- Read the validation resultFailures are reported with the path to the offending field, so you know exactly where to look.
- Test the failing cases tooA schema that accepts everything is not validating anything. Confirm bad data is actually rejected.
Why a missing field passes validation
In JSON Schema, properties only describe fields when they are present. A field is mandatory only if it is listed in the required array, and extra fields are allowed unless you set additionalProperties to false. Those two rules explain most schemas that seem to accept bad data.
Validate API requests and responses, config files and test fixtures against the schema, so a wrong type or a missing field is caught before it breaks something downstream.
Key features
- Catches malformed data at the boundary rather than deep inside your application.
- Reports the path to each failure, so debugging is immediate.
- Runs in your browser - API payloads containing real data are never transmitted.
- Lets you develop a schema iteratively against real examples.
- No account and no size limit.
Common uses
- Validating an API request or response against its contract.
- Checking a configuration file before deployment.
- Testing a schema you are writing against real sample data.
- Debugging why a payload is being rejected by a service.
- Documenting the expected shape of data for other developers.
Tips for better results
- Set additionalProperties to false when you want typos caught. By default a schema silently allows fields it never declared.
- Test with invalid data as well as valid. A schema that passes everything gives false confidence.
- Use "required" explicitly - listing a field under properties does not make it mandatory, which is a very common misunderstanding.
- Note that type: "number" accepts decimals; use "integer" when you mean whole numbers only.
- If the JSON itself will not parse, fix that first with the JSON Formatter - a syntax error is not a schema failure.
Mistakes to avoid
- Assuming a field listed in properties is required. It is not - required is a separate array.
- Leaving additionalProperties at its default, so a misspelled key passes validation while the real field is missing.
- Using "number" where "integer" was meant, letting 3.7 through as a quantity.
- Only testing data you expect to pass, so the schema is never proven to reject anything.
- Writing a schema so strict it breaks on every legitimate future addition to the payload.
Frequently asked questions
It follows standard JSON Schema conventions covering the most commonly used validation keywords (types, required fields, patterns, ranges) - check specific advanced/newer draft features against your schema if you rely on less common keywords.
The tool reports which parts of the data violate the schema - such as a missing required field, wrong data type, or a value outside an allowed range - so you can pinpoint and fix the issue.
For this tool, yes. If you have sample data but no schema, the JSON Schema Generator produces one from it, which you can then tighten by hand.
Because additionalProperties defaults to true, so any field the schema does not mention is allowed. Set it to false and unexpected keys - including misspelled ones - become validation errors.
Listing a field under properties describes it but does not make it mandatory. Fields are only required when named in the separate "required" array - this catches almost everyone at least once.
No. Validation runs in your browser, which matters because the payloads people validate are usually real API traffic containing customer data.
OpenAPI uses it to describe request and response bodies, editors such as VS Code use it for autocomplete in config files, and APIs use it to reject bad input early. LLM tool-calling and structured-output features also describe expected JSON with it.
Paths such as /items/2/price point to the exact value that failed: the price field of the third item (arrays count from zero). Fix that value or the rule, then validate again.
Yes, with the format keyword - 'email', 'date', 'date-time', 'uri' and others. Some validators treat format as a hint rather than a hard rule, so test a known-bad value to confirm it is being enforced.