JSON Schema Validator — Free Online JSON Schema Tester, Checker & Playground

Paste a JSON document and a JSON Schema to test validity instantly. Get precise error paths (JSON Pointer, e.g. $.users[2].email) — not a bare "invalid". Supports draft 2020-12, 2019-09 and Draft-07, $ref, format assertions, and YAML schemas.

What is a JSON Schema validator — and what is it used for?

A JSON Schema validator checks whether a JSON document conforms to a JSON Schema: a declarative contract describing the allowed structure, data types, required fields, value ranges, string patterns, and formats. Think of it as "TypeScript types for JSON data at runtime".

Common uses:

• API contracts — validate requests and responses before bad data propagates.
• Configuration files — reject misconfigured deploys with a clear error instead of a 3 a.m. outage.
• Data pipelines — gate ingested JSON before it reaches your warehouse.
• Forms & SDKs — generate validation logic from one shared schema.

JSON validator vs JSON Schema validator: a plain JSON validator (or "JSON checker") only verifies syntax — is it well-formed JSON? A JSON Schema validator goes further and verifies semantics against your schema: right types, required fields present, numbers in range, strings matching patterns, emails that look like emails.

How does JSON Schema validation work?

The validator walks the JSON document and the schema in parallel. For every value it applies the schema keywords that target it:

1. type checks the value's kind (object, array, string, number, integer, boolean, null).
2. Object keywords (properties, required, additionalProperties, patternProperties) check each member.
3. Array keywords (items/prefixItems, minItems, uniqueItems) check each element.
4. String/number keywords (minLength, pattern, minimum, multipleOf, format) constrain the value itself.
5. Combinators (allOf, anyOf, oneOf, not, if/then/else) compose schemas.

Every violation is reported with the JSON Pointer path of the failing value — e.g. $.users[2].email — so you know exactly where it broke. Enable Explain mode above and each error is also translated into plain language ("The value at $.age is out of the allowed numeric range: -5 is less than the minimum 0.").

How to use this JSON Schema validator

1. Paste your schema on the left (JSON, or YAML with "Schema is YAML" checked).
2. Paste the JSON document to test on the right.
3. Pick the draft your schema targets (2020-12, 2019-09, or Draft-07).
4. Validation runs live as you type. Click any error to jump to its exact location in the document.

Try the Sample dropdown, then "Load failing example" to see precise error paths in action. Toggle "Enforce format" off if your schema uses format only as documentation (per spec, format is annotation-only by default; this tool lets you opt into assertion).

JSON Schema data types & core keywords

The six JSON types plus integer: object, array, string, number, integer, boolean, null. Key constraining keywords:

{
  "type": "object",
  "properties": {
    "name":  { "type": "string", "minLength": 1, "maxLength": 80 },
    "code":  { "type": "string", "pattern": "^[A-Z]{2}-\\d{4}$" },
    "price": { "type": "number", "exclusiveMinimum": 0, "multipleOf": 0.01 },
    "tags":  { "type": "array", "items": { "type": "string" },
               "minItems": 1, "uniqueItems": true },
    "role":  { "enum": ["admin", "editor", "viewer"] },
    "kind":  { "const": "user" }
  },
  "required": ["name", "role"],
  "additionalProperties": false
}

oneOf vs anyOf (and allOf / not)

{"anyOf": [
  {"type": "string"},
  {"type": "string",
   "format": "email"}
]}

{"oneOf": [
  {"type": "object",
   "properties": {
     "w": {"type": "number"},
     "h": {"type": "number"}},
   "required": ["w","h"]},
  {"const": "digital"}
]}

allOf requires matching every subschema (great for mixing reusable fragments); not forbids matching a subschema.

$ref, $defs, anchors & recursion

$ref reuses a schema defined elsewhere — no copy-paste. This tool resolves internal references: local JSON Pointers (#/$defs/address), relative refs, plain-name anchors ($anchor), and the draft-specific dynamic keywords $dynamicRef (2020-12) and $recursiveRef (2019-09).

{
  "$defs": {
    "address": {
      "type": "object",
      "properties": {
        "street": { "type": "string" },
        "zip":    { "type": "string", "pattern": "^\\d{5}(-\\d{4})?$" }
      },
      "required": ["street", "zip"]
    }
  },
  "type": "object",
  "properties": {
    "home": { "$ref": "#/$defs/address" },
    "work": { "$ref": "#/$defs/address" }
  }
}

Remote $ref (http/https URLs) is intentionally not fetched — the tool is 100% offline, so there is no network to fetch with. Inline the referenced schema into $defs instead. Circular $refs are handled safely.

additionalProperties — strict schemas

By default, objects may contain properties not listed in properties. Set "additionalProperties": false for a strict schema that rejects unknown keys — the error names the offending property. Use patternProperties when extra keys are allowed but must follow a shape:

{
  "type": "object",
  "properties": { "name": { "type": "string" } },
  "patternProperties": { "^x-": { "type": "string" } },
  "additionalProperties": false
}

Here x-anything keys are allowed (and must be strings); any other undeclared key fails. Draft 2020-12 also offers unevaluatedProperties, which understands allOf/oneOf compositions — both are supported by this validator.

Conditional validation: if / then / else & dependentRequired

For rules like "conditional required" — field B is required only when field A has a certain value — use if/then/else:

{
  "type": "object",
  "properties": {
    "country":    { "type": "string" },
    "postalCode": { "type": "string" }
  },
  "if":   { "properties": { "country": { "const": "USA" } },
            "required": ["country"] },
  "then": { "properties": { "postalCode":
            { "pattern": "^\\d{5}(-\\d{4})?$" } } },
  "else": { "properties": { "postalCode": { "minLength": 3 } } }
}

For simpler co-occurrence ("if credit_card is present, billing_address is required"), dependentRequired: { "credit_card": ["billing_address"] } (2020-12; dependencies in Draft-07) is enough. Try the if/then/else sample above.

Optional fields & nullable types ("string or null")

Properties are optional by default — only names listed in required must appear. To additionally allow an explicit null value (a "string or null" field), widen the type:

{
  "type": "object",
  "properties": {
    "nickname": { "type": ["string", "null"] },
    "email":    { "type": "string", "format": "email" }
  },
  "required": ["email"]
}

{"email": "a@b.co"} is valid (nickname omitted); {"email": "a@b.co", "nickname": null} is valid; {"email": "a@b.co", "nickname": 42} fails.

Nested objects & arrays of objects

Nest properties to any depth; describe each array element with items. Error paths track the full descent — $.orders[0].lines[2].price:

{
  "type": "object",
  "properties": {
    "customer": {
      "type": "object",
      "properties": {
        "name":    { "type": "string" },
        "address": { "$ref": "#/$defs/address" }
      },
      "required": ["name"]
    },
    "orders": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "sku":   { "type": "string", "pattern": "^[A-Z0-9-]+$" },
          "price": { "type": "number", "minimum": 0 }
        },
        "required": ["sku", "price"]
      },
      "minItems": 1
    }
  },
  "required": ["customer", "orders"]
}

Format validators: email, date, URL, UUID & more

With "Enforce format" enabled, string formats are asserted (disable it to treat them as annotations, per the spec default):

String patterns use the pattern keyword with regex (ECMA-262): { "type": "string", "pattern": "^[a-z0-9-]+$" }.

JSON Schema in YAML — validator & examples

JSON is valid YAML, and schemas are often authored in YAML for readability. Check "Schema is YAML" and paste a YAML schema — mappings, nested blocks, and sequences are converted before validation:

type: object
properties:
  name:
    type: string
    minLength: 1
  email:
    type: string
    format: email
  tags:
    type: array
    items:
      type: string
required:
  - name
  - email
additionalProperties: false

Flow collections (type: [string, "null"]), quoted strings, numbers, booleans, and comments are supported. The instance document stays JSON.

Draft 2020-12 vs 2019-09 vs Draft-07

Pick the draft your schema declares via $schema (the toolbar selector overrides for testing). All three are fully supported, including the tricky bits: outermost-wins $dynamicRef, $recursiveRef scoping, and unevaluated* evaluation tracking.

OpenAPI JSON Schema validation

OpenAPI 3.1 schemas are a dialect of JSON Schema draft 2020-12 — paste them here and they validate directly (including $defs, prefixItems, and const). OpenAPI 3.0 uses an older subset: replace $defs with definitions, rewrite boolean exclusiveMinimum/exclusiveMaximum as numbers, and note that 3.0's nullable: true becomes "type": ["string", "null"].

Custom error messages

JSON Schema has no standard errorMessage keyword (that's an AJV extension). The portable approach: use Explain mode in this tool, which renders every failure as a human sentence with its exact path — or add title/description annotations to document intent for API consumers.

Comparison: this validator vs alternatives

Validator vs generator — and related tools

A JSON Schema validator tests documents against a schema; a generator creates a schema from sample JSON (or sample data from a schema). Different intents — this page is the validator. If you need the other direction, nrtechstudio.com also hosts a JSON-to-JSON-Schema generator and a JSON Schema viewer.

Frequently asked questions