UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

JSON Schema Validator

Validate JSON data against a JSON Schema (Draft-07, Draft-2019-09, Draft-2020-12) and see detailed validation errors.

About JSON Schema Validator

The JSON Schema Validator checks JSON data documents against a provided JSON Schema, reporting whether the document is valid and listing any validation errors with their exact JSON Pointer paths. It supports JSON Schema Draft-07, Draft-2019-09, and Draft-2020-12 — covering all keyword sets from basic type validation ($type, required, properties) through advanced composition (anyOf, allOf, oneOf, $if/$then/$else) and format validators. Validation errors are shown with the path to the failing element and a human-readable description of the violation, making debugging schemas and data fast and accurate.

Why use JSON Schema Validator

  • Supports all three modern JSON Schema drafts including Draft-2020-12.
  • Error messages include JSON Pointer paths to the failing element.
  • Handles complex schemas with $ref, anyOf, allOf, oneOf, and conditional keywords.
  • Both panels have syntax highlighting and format-on-paste for readability.
  • Supports all three modern JSON Schema drafts including Draft-2020-12 (the current standard).
  • Error messages include JSON Pointer paths to the failing element — no manual hunting through nested objects.

How to use JSON Schema Validator

  1. Paste your JSON Schema into the left panel.
  2. Paste the JSON data document you want to validate into the right panel.
  3. Select the JSON Schema Draft version.
  4. Click Validate — pass/fail status and error details appear immediately.
  5. Select the JSON Schema Draft version (Draft-07, Draft-2019-09, or Draft-2020-12).
  6. Click any error entry to jump to the failing JSON Pointer location in the data panel.
  7. Use the example schema/data buttons to load a working pair when you want to learn the syntax.

When to use JSON Schema Validator

  • Debugging why API request/response data fails schema validation.
  • Developing and testing JSON Schemas for APIs or configuration files.
  • Validating configuration files before deployment.
  • Checking that generated JSON matches a shared contract schema.
  • Debugging why API request/response data fails schema validation in production logs.
  • Validating configuration files (e.g. eslint, prettier, package.json) before deployment.

Examples

Simple object validation

Input: Schema: { type: 'object', required: ['name'], properties: { name: { type: 'string' } } } Data: { "name": "Ada" }

Output: Valid — required field present and type matches.

Missing required field

Input: Same schema as above. Data: { "age": 36 }

Output: Invalid: '/' must have required property 'name'

anyOf composition

Input: Schema: { anyOf: [ { type: 'string' }, { type: 'number' } ] } Data: true

Output: Invalid: '/' must match a schema in anyOf — boolean does not satisfy string or number.

Format assertion

Input: Schema: { type: 'string', format: 'email' } Data: "not-an-email"

Output: Invalid: '/' must match format 'email' (when format assertion enabled).

Tips

  • Set additionalProperties: false at the top of object schemas to catch typos in property names — a common source of bugs.
  • Use $defs (Draft-2019-09+) instead of definitions for reusable subschemas — it's the modern keyword.
  • Prefer enum for closed sets of values (e.g. status: 'active' | 'archived'), and use pattern only when string format requires regex.
  • Test edge cases: empty arrays, null values, and missing optional fields. Each often surfaces a schema gap.
  • When migrating between drafts, the biggest changes are: 'definitions' → '$defs', 'id' → '$id', and the dependent schemas split (Draft-2019-09).
  • Use format: 'date-time' for ISO 8601 timestamps; format: 'email' for RFC-validated email addresses. Both validate when format assertion is enabled.

Frequently Asked Questions

Which JSON Schema drafts are supported?
Draft-07, Draft-2019-09 (formerly Draft-8), and Draft-2020-12. Draft-04 and Draft-06 are partially supported through backward compatibility.
What is a JSON Pointer?
A JSON Pointer (RFC 6901) is a string like /data/items/0/name that identifies a specific value within a JSON document. Validation errors include the pointer to the failing location.
Does it support $ref?
Yes. Internal $ref references within the schema document are resolved. External URL $refs require the target schema to be inlined.
Can it validate format keywords like 'email' or 'date-time'?
Yes. Common format keywords (email, uri, date, date-time, uuid, ipv4, ipv6) are validated when format assertion is enabled.
Is there a size limit on the JSON data?
There is no hard limit, but very large documents (multi-MB) may cause the browser to slow. For production validation, use a server-side validator.
Does the validator coerce types?
No. JSON Schema does not coerce types: '5' (string) fails type: 'number'. Pre-process inputs (e.g. URL query strings) before validation if needed.
What's the difference between additionalProperties: false and unevaluatedProperties?
additionalProperties: false rejects properties not declared in 'properties'. unevaluatedProperties (Draft-2019-09+) is smarter — it considers properties matched by anyOf/allOf branches before rejecting, helpful for composed schemas.

Explore the category

Glossary

JSON Schema
A vocabulary that allows you to annotate and validate JSON documents. Specified at json-schema.org with multiple draft versions over time.
Draft versions
Successive specifications of JSON Schema. Draft-07 is widely adopted; Draft-2019-09 added $defs and dependent schemas; Draft-2020-12 is the current standard with prefixItems and updated $ref semantics.
$ref
A keyword that references another schema by URI, JSON Pointer, or local fragment. Allows reuse of common subschemas without duplication.
$defs
Modern keyword (Draft-2019-09+) for declaring reusable subschemas. Replaces 'definitions' from earlier drafts. Referenced via #/$defs/<name>.
additionalProperties
Controls whether objects may contain properties not listed in 'properties'. Set to false to enforce strict shape; set to a schema to validate unknown properties.
Type coercion
JSON Schema validation does NOT coerce types — '1' (string) does not match type: 'number'. Coerce input data with code if your transport (e.g. query strings) sends strings.
JSON Pointer
RFC 6901 syntax (e.g. /data/items/0/name) for addressing values within a JSON document. Used in $ref and validation error paths.
Format keyword
Annotates strings with semantic types (email, uri, date-time, uuid). Validators may assert (enforce) or annotate (informational only) — controlled by configuration.