JSON Schema Validator

Checking data against a contract

A validator takes two inputs, a JSON Schema and a JSON document, and reports whether the document satisfies the schema. Unlike a formatter that only checks syntax, this checks meaning: correct types, required keys present, values inside their allowed ranges, strings matching their patterns. When something fails, a good validator points at the exact path that broke the rule.

Example

Schema requires an integer age:

{
  "type": "object",
  "properties": { "age": { "type": "integer", "minimum": 0 } },
  "required": ["age"]
}

Data that fails:

{ "age": -3 }
Error at /age: -3 is less than minimum 0

Why path-based errors matter

In a deeply nested payload, "validation failed" is useless. The value of a validator is the pointer, something like /items/2/price, telling you the third item's price is wrong. That turns a guessing game into a one-line fix. Draft-07 uses JSON Pointer syntax for these paths.

Gotchas that surprise people

By default, extra properties not listed in the schema are allowed; you must set additionalProperties: false to reject them. The integer type rejects 1.0 in some implementations and accepts it in others depending on how the number was parsed. And a null is not the same as a missing key, a nullable field needs type to include "null".

FAQ

Why did my extra field pass? Schemas are permissive by default. Add additionalProperties: false to forbid unlisted keys.

Where do I get a schema to start from? Infer one from a sample with JSON to JSON Schema, then tighten the rules before validating.