JSON Schema Validator Online
Check whether a JSON document matches a schema in your browser. This validator supports the everyday JSON Schema rules most useful for API payloads: types, required properties, nested properties, array items, enums, constants, string and number limits, regular-expression patterns, array sizes, and disallowed extra keys. Errors include a JSON path such as `$.user.email` or `$.items[2]`, making the first useful correction easier to find. Both the data and the schema stay in this tab. It is a deliberately documented subset, not a claim to implement every draft, reference resolver, conditional keyword, or vocabulary in the JSON Schema standard.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — free{ path, required, type, pattern } checks, evaluated entirely in your browser.- id: required but missing
What it does
- Object, array, string, number, integer, boolean, and null types
- Required and additional property checks
- Nested properties and array item rules
- Enum, const, length, numeric, pattern, and item limits
- JSON-path validation messages
How to use JSON Schema Validator
- 1
Paste the JSON data
Paste the API response, fixture, or configuration object into the data panel. It must be strict JSON, so comments and trailing commas are rejected by the parser.
- 2
Paste the schema
Add a schema object using the supported keywords. Start with type, required, and properties, then add limits that express the contract you actually need.
- 3
Read each issue
A valid result means no supported rule failed. Invalid output lists paths and messages, while malformed data or schema JSON is reported separately.
- 4
Test representative cases
Try a valid payload, a missing property, a wrong type, and an unexpected key. This catches a weak schema before it becomes a false confidence check in a test suite.
How it works
Contract versioning
Record the schema version and sample payload with the validation result. A valid payload can still be wrong for an older or newer API contract.
Validate the right contract
Check that the schema's required fields, types, formats, and additional-property rules match the version of the API you are testing. A document can be valid JSON and still fail its schema, while a valid schema can describe a contract that is outdated. Test representative success and failure samples, keep secrets out of copied payloads, and read the first validation path before changing the document. Validation reports shape; it does not prove that a value is semantically correct.
The page parses both panels as strict JSON and walks the data against the schema from
the root. Type rules run before the type-specific checks. Object rules inspect required
keys, known property schemas, and the optional additionalProperties: false boundary.
Array item rules are applied to each entry, with paths that include the numeric index.
The validator stops recording after 100 issues so a malformed large payload cannot
make the result panel unusable.
The supported checks are intentionally visible in the tool note. There is no remote
$ref fetch, no custom format registry, no code execution, and no schema guessing.
Regular-expression patterns are constructed locally and invalid patterns become a
reported schema issue. This makes the page useful for common contracts while keeping
its behavior predictable and safe to explain.
When to use it
Use this for an API response sample, a frontend fixture, a webhook payload, or a quick schema review before writing tests. Try both passing and failing examples, especially when optional fields and extra properties matter. For a production validator, pin a JSON Schema library and draft version in your application so references, formats, combinators, and error semantics are controlled by your own test suite.
Examples
Validating a user payload
The age property is optional in this schema but, when present, must be a non-negative integer. Required and optional fields can therefore be expressed separately rather than treating every property as mandatory.
Finding a missing field and extra key
The root issue and property path distinguish an absent contract field from an unexpected field. That difference is useful when tightening an API payload.
Frequently asked questions
Does this implement the complete JSON Schema specification?
No. It implements a practical local subset: type, required, properties, items, enum, const, string and number limits, pattern, array limits, and additionalProperties set to false. It does not resolve references or implement every combinator, conditional, format, annotation, or draft vocabulary. Use a full JSON Schema library in production when those features affect correctness.
Why does the validator show a JSON path for an error?
The path identifies the value being checked, such as $.profile.email for a nested property or $.items[2] for an array entry. The root path `$` is used for missing required properties and document-level rules. Paths make a failed API fixture easier to correct than a generic message saying only that validation failed.
Can I use comments or trailing commas in the schema?
No. Both the data and schema are parsed with the browser's strict JSON parser. JSON Schema is represented as JSON, so comments, single-quoted strings, and trailing commas need to be removed or handled by a separate editor before this page can evaluate the rules.
Is the JSON sent to a server?
No. Parsing and validation happen in the browser, and the page does not send the data or schema to an API. Keep in mind that browser extensions, screen capture, and device administration are outside this page's privacy boundary when you test payloads containing tokens or personal records.