Which validation engine does it use?

It uses AJV, the same fast, spec-compliant validator many production systems rely on, so results match what your backend would produce.

Does it report all errors or just the first?

It collects all validation errors in one pass, each with the instance path and the keyword that failed, so you can fix everything at once.

Which JSON Schema drafts are supported?

Modern drafts and their common keywords are supported, including type, required, enum, pattern, format, and numeric and length constraints.

How do I validate JSON against a schema?

Paste your JSON Schema and the document to check, then the validator runs AJV and lists every violation with its exact instance path and the rule that failed. Fix each issue and re-run until it passes.

Which JSON Schema keywords are supported?

Common keywords across modern drafts are supported, including type, required, enum, pattern, format, and numeric and string length constraints.

Is my data safe or uploaded anywhere?

Both the schema and the data are validated entirely in your browser. Nothing is uploaded, so your documents stay private.

JSON Schema Validator

Stable

Validate JSON against a JSON Schema using AJV.

Everything is processed locally in your browser

About JSON Schema Validator

The JSON Schema Validator checks a JSON document against a JSON Schema using AJV, the standard high-performance validator. It reports every violation with the exact instance path and the rule that failed, so you know precisely what to fix. Use it to enforce contracts on API payloads, config files, and any structured data.

Features

Validation powered by AJV, the widely used JSON Schema engine
Path-level error messages that name the failing property and rule
Supports modern JSON Schema drafts and common keywords
Validates types, required fields, enums, patterns, and ranges
Reports all errors at once, not just the first failure
Works with schemas you author or generate from a sample

How to use JSON Schema Validator

1
Provide a JSON Schema
Paste the schema that defines the rules your data must satisfy.
2
Provide the JSON to check
Add the document you want to validate against that schema.
3
Validate
AJV checks the document and lists any violations with their paths.
4
Fix and re-run
Correct each reported issue and validate again until the document passes.

Examples

A document that fails validation

The age is below the schema minimum.

Input

// schema
{ "type": "object",
  "properties": { "age": { "type": "integer", "minimum": 18 } },
  "required": ["age"] }

// data
{ "age": 15 }

Output

Invalid: /age must be >= 18 (minimum).

How JSON Schema validation works

The validation that actually prevents bugs

Syntax validation tells you a document is well-formed. Schema validation tells you it is correct - that the required fields are present, the types are right, the numbers are in range, the strings match their expected shape, and no unexpected keys have crept in. That is the check that stops bad data reaching your business logic.

The payoff is concentrated at system boundaries. Validating an incoming request body means a handler can assume its input is well-shaped rather than defending against every field being absent or wrong. Validating an outgoing payload in tests catches contract breakage before a consumer discovers it in production. Validating configuration at startup turns a mysterious runtime failure into a clear error message at boot, which is a large improvement in operability for very little work.

Draft versions, and why they matter more than you would like

JSON Schema has evolved through several drafts, and they are not fully interchangeable. Draft-07 is still the most widely deployed and is what most tooling assumes by default. Draft 2019-09 introduced `$defs` in place of `definitions` and added annotation vocabularies. Draft 2020-12 is current and changed array handling significantly: tuple validation moved from `items` as an array to `prefixItems`, which is a breaking change for any schema that used the old form.

OpenAPI adds its own wrinkle. OpenAPI 3.0 used a modified subset of Draft-04 with its own `nullable` keyword; OpenAPI 3.1 aligned properly with Draft 2020-12 and dropped `nullable` in favour of type unions. Schemas copied between the two need adjustment.

The practical rule is to declare `$schema` explicitly at the top of every schema. Without it, validators guess, and a schema written for one draft but validated as another can silently ignore keywords it does not recognise - which means constraints you thought you had are simply not being applied.

Reading validation errors

A validation failure gives you an instance path - where in the document the problem is - and a schema path saying which rule was violated. Reading both together is what makes the message actionable: the instance path locates the data, the schema path explains the expectation.

The errors that confuse people are the ones from `oneOf` and `anyOf`. When a document fails to match any branch of a union, a validator typically reports the failures from every branch, which can be a long list describing several alternatives that were all rejected. The useful technique is to find the branch that got furthest before failing - that is almost always the one you intended - and fix against that, ignoring the rest.

`additionalProperties: false` produces the other commonly misread error. A complaint about an unexpected property usually means a typo in a key name, or a client sending a field the schema has not been updated to allow.

Reference

JSON Schema drafts

Draft	$schema identifier	Notes
Draft-07	http://json-schema.org/draft-07/schema#	Most widely supported; a safe default
2019-09	https://json-schema.org/draft/2019-09/schema	`definitions` becomes `$defs`
2020-12	https://json-schema.org/draft/2020-12/schema	Current; tuples move to `prefixItems`
OpenAPI 3.0	(subset of Draft-04)	Has its own `nullable` keyword
OpenAPI 3.1	(aligned with 2020-12)	`nullable` dropped for type unions

Which tool should you use?

These tasks overlap. Here is how to pick the right one for what you are actually doing.

Documents parse but break your application: This is precisely the gap schema validation fills. Syntax checking cannot see missing fields or wrong types.
You do not have a schema yet: Generate a draft with the JSON Schema Generator, then prune `required` and add constraints.
You only need to know if the JSON is well-formed: The JSON Validator is simpler and sufficient.
You want validation running continuously: Wire Ajv or a similar library into your CI and request handlers. Interactive validation is for authoring and debugging schemas.

Use cases

Enforcing a contract on incoming API request bodies
Verifying config files conform to a defined schema before deploy
Testing that generated data matches an agreed structure
Catching missing required fields or wrong types early
Validating user-submitted JSON against documented rules

Troubleshooting common errors

A keyword in the schema appears to be ignored

Why: A draft mismatch. Validators skip keywords they do not recognise rather than erroring, so a 2020-12 keyword under a Draft-07 validator does nothing.

Fix: Set `$schema` explicitly and confirm the validator supports that draft. This failure is silent, which makes it worth checking first.

Every optional field is being reported as missing

Why: They are listed in `required` - typically because the schema was generated from a complete sample.

Fix: Remove them from `required`. Optionality is expressed only by absence from that array.

A oneOf failure produces a wall of errors

Why: The validator reports why each branch was rejected, so you see every alternative's failures at once.

Fix: Identify the branch that progressed furthest and correct against that. Adding a discriminator field makes future errors far more precise.

"must NOT have additional properties"

Why: `additionalProperties: false` and the document contains a key the schema does not define - often a misspelled one.

Fix: Check the spelling against the schema. If the field is legitimate, add it to `properties`.

A `format` constraint does not reject an invalid value

Why: `format` is annotation-only by default in newer drafts, and needs to be explicitly enabled as an assertion.

Fix: Enable format validation in your validator - `ajv-formats` for Ajv - or add a `pattern` alongside it.

Limitations

What this tool deliberately does not do, so you know when to reach for something else.

Validation is only as strong as the schema; a permissive schema passes almost anything.
Cross-field rules such as "end date must follow start date" are outside what JSON Schema expresses.
`format` is annotation-only by default in recent drafts and must be enabled to assert.
Draft differences mean unrecognised keywords are silently skipped rather than reported.
External `$ref` URLs are not fetched; referenced schemas must be inlined.

Frequently asked questions

JSON Schema Generator

Infer a JSON Schema from a sample JSON document.

JSON Validator

Validate JSON syntax and pinpoint the exact line and column of any error.

JSONPath Evaluator

Query JSON with JSONPath expressions and see live results.

Online JSON Formatter & Validator

Pretty-print JSON with configurable indentation and instant validation.

Learn more

How to Validate JSON Against a Schema (With AJV, In Your Browser)A JSON document can be well-formed and still be wrong. This guide explains JSON Schema validation, how AJV catches contract violations, and how to check your data with precise, path-level errors.