JSON Schema Validator

Your API accepts a JSON body with 15 required fields, nested objects, arrays of specific types, and string patterns (email, URL, date). You wrote a JSON Schema but aren’t sure if it correctly rejects invalid payloads — does it catch a missing email field? Does it reject "age": "twenty-five" when the schema says "type": "integer"? You need to test the schema against sample data before deploying it.

Why This Validator (Not the JSON Schema Generator)

PureDevTools has a JSON Schema Generator for creating schemas from sample JSON. This tool validates data against an existing schema — paste your schema and your data, see detailed error paths, expected vs actual values, and which schema keyword failed. Supports Draft 4, 6, 7, 2019-09, and 2020-12. Everything runs in your browser; no data is sent anywhere.

What Is JSON Schema?

JSON Schema is a declarative language for describing the structure and constraints of JSON data. It is widely used for API contract validation, configuration file linting, form validation, and data pipeline quality checks. The specification is maintained by the JSON Schema organization and has gone through several drafts: Draft 4, Draft 6, Draft 7, Draft 2019-09 (also called Draft 8), and Draft 2020-12. While the drafts differ in details, the core vocabulary is compatible across them, and this validator supports the most common keywords from all drafts.

A schema is itself a JSON document (or the literal true / false). When a schema is true, any value is valid. When it is false, nothing is valid. Practically all schemas are objects that declare rules through keywords such as type, properties, required, and items.

Core Schema Keywords

Type Validation

The type keyword constrains which JSON types are allowed. Valid type names are "string", "number", "integer", "boolean", "array", "object", and "null". You can also specify an array of types to allow multiple:

{ "type": ["string", "null"] }

Note that "integer" is a subset of "number" — any integer value satisfies a "number" type, but 3.14 does not satisfy "integer".

Enumerations and Constants

Use enum to restrict a value to a fixed set:

{ "enum": ["admin", "user", "guest"] }

Use const to require an exact value:

{ "const": "production" }

Object Validation

Objects are validated with properties (schemas for known keys), required (list of mandatory keys), and additionalProperties (constraint on unknown keys):

{
  "type": "object",
  "required": ["id", "name"],
  "properties": {
    "id":   { "type": "integer", "minimum": 1 },
    "name": { "type": "string",  "minLength": 1 }
  },
  "additionalProperties": false
}

Setting additionalProperties to false makes the schema strict — any property not listed in properties or matched by patternProperties causes a validation error.

patternProperties applies a schema to every key that matches a regular expression:

{
  "patternProperties": {
    "^str_": { "type": "string" }
  }
}

Array Validation

Arrays are validated with items (schema for every element or a positional tuple), minItems, maxItems, and uniqueItems:

{
  "type": "array",
  "items": { "type": "string" },
  "minItems": 1,
  "maxItems": 100,
  "uniqueItems": true
}

For tuple validation (where each position has a distinct type), use an array of schemas for items (Draft 4–7) or prefixItems (Draft 2020-12):

{
  "prefixItems": [
    { "type": "string" },
    { "type": "integer" },
    { "type": "boolean" }
  ]
}

String Constraints

Strings support minLength, maxLength, pattern (a ECMA-262 regular expression), and format:

{
  "type": "string",
  "minLength": 8,
  "maxLength": 64,
  "pattern": "^[a-zA-Z0-9_]+$"
}

Common format values: "date-time", "date", "time", "email", "uuid", "uri", "ipv4", "hostname".

Number Constraints

Numbers support minimum, maximum, exclusiveMinimum, exclusiveMaximum, and multipleOf:

{
  "type": "number",
  "minimum": 0,
  "maximum": 1,
  "multipleOf": 0.01
}

In Draft 4, exclusiveMinimum and exclusiveMaximum were booleans paired with minimum/maximum. From Draft 7 onwards they are numbers themselves.

Combining Schemas

allOf, anyOf, oneOf, not

• allOf: data must be valid against all sub-schemas
• anyOf: data must be valid against at least one sub-schema
• oneOf: data must be valid against exactly one sub-schema
• not: data must be invalid against the sub-schema

{
  "oneOf": [
    { "type": "string" },
    { "type": "number", "minimum": 0 }
  ]
}

if / then / else

Conditional schemas (Draft 7+): if if validates, then then is applied; otherwise else is applied:

{
  "if":   { "properties": { "type": { "const": "human" } }, "required": ["type"] },
  "then": { "required": ["name"] },
  "else": { "required": ["id"] }
}

$ref and Reusable Definitions

Use $defs (Draft 2019-09+) or definitions (older) to define reusable sub-schemas, and reference them with $ref:

{
  "$defs": {
    "address": {
      "type": "object",
      "required": ["street", "city"],
      "properties": {
        "street": { "type": "string" },
        "city":   { "type": "string" }
      }
    }
  },
  "properties": {
    "home":  { "$ref": "#/$defs/address" },
    "work":  { "$ref": "#/$defs/address" }
  }
}

This validator resolves local $refs (those starting with #).

Understanding Validation Errors

Each error in this tool shows:

• Path — the JSON Pointer to the failing data location (e.g. /users/0/email)
• Keyword — which schema keyword triggered the error (e.g. type, required, pattern)
• Message — a human-readable explanation
• Expected / Actual — the constraint value and the actual data value
• Schema path — where in the schema the rule lives (e.g. #/properties/email/format)

A JSON Pointer of (root) means the error applies to the top-level data document, not a nested property.

Frequently Asked Questions

What JSON Schema drafts does this tool support? This tool validates against a combined keyword set covering Draft 4, Draft 6, Draft 7, Draft 2019-09, and Draft 2020-12. Keywords unique to newer drafts (such as prefixItems, dependentRequired, dependentSchemas) are supported alongside the classic keywords.

Does this tool perform strict draft-specific validation? No. It implements the most widely used keywords across all drafts rather than enforcing strict draft isolation. This is the most practical approach for day-to-day schema validation where schemas mix keywords from different drafts.

Why does my valid JSON fail with “additional property” errors? When additionalProperties: false is set, every property in the data must be declared in properties or matched by patternProperties. Add the unexpected property to your schema’s properties definition, or remove additionalProperties: false if you want to allow arbitrary extra fields.

What is the difference between anyOf and oneOf? anyOf passes if one or more sub-schemas match. oneOf requires exactly one sub-schema to match — it fails if zero or more than one match. Use anyOf for “at least one of these shapes”, and oneOf when the options are mutually exclusive.

Does this tool send my data to a server? No. All JSON parsing and schema validation runs entirely in your browser using JavaScript. No data is transmitted to any server — your schema and JSON data stay on your device.

What is the $ref keyword? $ref allows you to reference another schema definition by its JSON Pointer. It eliminates duplication when the same sub-schema appears in multiple places. This tool supports local references (starting with #), which point into the same schema document.

Can I validate nested arrays of objects? Yes. Nest schemas as deeply as needed:

{
  "type": "array",
  "items": {
    "type": "object",
    "required": ["id"],
    "properties": {
      "id": { "type": "integer" },
      "tags": {
        "type": "array",
        "items": { "type": "string" }
      }
    }
  }
}