How to Validate JSON with JSON Schema
Checking that JSON is syntactically valid only gets you so far — it tells you the braces balance, not that the data is shaped the way your code expects. JSON Schema fills that gap. It's a standard vocabulary for describing the structure of a JSON document, and a schema validator checks a real document against that contract. This guide covers what JSON Schema is, the keywords you'll use most, and how to validate a document and read the results.
What is JSON Schema?
JSON Schema is itself written in JSON, and it describes what a valid document looks like: which properties exist, what type each one holds, which are required, and what values are allowed. It's the contract that sits between systems — the thing that lets an API say "send me an object with an integer id and a non-empty name" and reject anything that doesn't comply.
Validation against a schema is far stronger than a syntax check. A document can be perfectly valid JSON and still be wrong for your purposes — missing a required field, holding a string where a number belongs, or carrying an unexpected extra key. A schema catches all of that.
A minimal schema
Most schemas start with a type of object, a properties map describing each field, and a required list. For example, a user schema might declare that the document is an object with an integer id of at least 1, a name string of minimum length 1, and an email string in email format — and that id, name, and email are all required. Setting additionalProperties to false then rejects any key you didn't describe.
The keywords you'll use most
A handful of keywords covers the vast majority of real schemas:
- type — string, number, integer, boolean, object, array, or null.
- properties and required — the fields of an object and which must be present.
- items — the schema every element of an array must satisfy.
- enum and const — restrict a value to a fixed set, or a single value.
- minimum / maximum and minLength / maxLength — numeric and string bounds.
- pattern — a regular expression a string must match.
- additionalProperties — whether keys beyond those described are allowed.
Validating a document and reading errors
To validate, you give the validator two things: the schema and the data. A good validator reports every violation at once, each pinned to the JSON Pointer path of the offending value — like /email or /roles/0 — with a plain reason such as "must have required property 'email'" or "must be integer".
Fix the violations one at a time and watch the list shrink to zero. Because the path points straight at the value, you never have to hunt through a large document to find what failed.
Where JSON Schema pays off
Schemas are most valuable at the boundaries of a system: validating request and response bodies for an API, checking configuration files before a deploy, guarding form submissions, and asserting the shape of fixtures in tests. Writing the schema once and validating against it everywhere keeps bad data out before it can cause damage downstream.
Try it yourself
Check that your JSON matches a JSON Schema — with every error pinpointed by path.