Gera Tools

JSON Schema Validator

Validate JSON documents against a JSON Schema (draft-07 / 2020-12)

Validate any JSON document against a JSON Schema and get each failure reported with its JSON Pointer path and a clear reason. Supports core draft-07 and draft 2020-12 keywords — types, required, enum, ranges, patterns, and nested objects and arrays. Runs in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Which JSON Schema keywords are supported?

Core validation keywords across draft-07 and 2020-12: type, required, properties, additionalProperties, items, enum, const, minimum, maximum, exclusiveMinimum, exclusiveMaximum, minLength, maxLength, pattern, minItems, maxItems, uniqueItems, minProperties, maxProperties, and the combinators allOf, anyOf, oneOf, and not.

JSON Schema Validator checks whether a JSON document conforms to a JSON Schema and pinpoints every failure. Instead of a single pass/fail, it lists each violation with a JSON Pointer path and a human-readable reason, so debugging a large payload is quick. It implements the core validation keywords shared by draft-07 and draft 2020-12, and runs entirely in your browser.

How it works

Validation walks the schema and the data together, starting at the root with the JSON Pointer "". At each node the validator applies the keywords present in the schema:

  • type / enum / const — checks the value’s JSON type or membership in a fixed set.
  • Numeric — minimum, maximum, exclusiveMinimum, exclusiveMaximum.
  • String — minLength, maxLength, and pattern (a regular expression).
  • Object — required, properties, additionalProperties, minProperties, maxProperties. Each property recurses with its key appended to the pointer.
  • Array — items (applied to every element, with the index appended to the pointer), minItems, maxItems, uniqueItems.
  • Combinators — allOf, anyOf, oneOf, and not aggregate sub-results.

Every failure pushes an entry holding the pointer and the reason, and the collected list is shown at the end.

Reading JSON Pointer paths in error output

JSON Pointer (RFC 6901) is a slash-separated path to a specific location in a JSON document. Understanding it makes errors instantly actionable:

PointerMeaning
“ (empty string)The root document itself
/nameThe top-level name field
/address/postCodeThe postCode field inside the address object
/tags/0The first element of the tags array
/orders/2/amountThe amount field of the third element of orders

So an error at /orders/2/amount means “the amount field in the third order object failed validation” — you can navigate directly to that field rather than searching.

A worked validation example

Schema:

{
  "type": "object",
  "required": ["name", "age"],
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "age":  { "type": "integer", "minimum": 0 },
    "email": { "type": "string", "pattern": "^[^@]+@[^@]+$" }
  }
}

Document (with two errors):

{ "name": "", "age": -5, "email": "not-an-email" }

Expected errors:

  • /name — minLength: string is too short (length 0, minimum 1)
  • /age — minimum: value -5 is less than minimum 0
  • /email — pattern: value does not match ^[^@]+@[^@]+$

Each error includes the path, so in a large API payload you can find the failing field without scanning the whole document.

Tips and notes

Because the validator does not fetch remote $ref targets, inline the full schema for complete coverage — this keeps the tool offline and your data private. The type keyword follows the JSON model: integer demands a whole number, null is its own type, and arrays are not objects. Try the bundled example, then tweak the document to see the pointer paths update as new errors appear.