JSON Schema Validator — Validate JSON Against a Schema

Validate JSON against a schema, in the browser

A JSON document can be perfectly well-formed and still be wrong. It parses, the braces balance, every string is quoted — and the API still returns a 422, because the quantity arrived as the string "2" instead of the number 2, or because a status field carried a value the service has never heard of. Syntax checking, which is what a normal JSON validator does, cannot catch any of that. Schema validation can, because a JSON Schema describes the shape your data is supposed to have: which properties are required, what type each one is, which values are allowed, how long a string may be, how few items an array may contain.

This page pairs your document with your schema and runs them through Ajv, the validator that most of the JavaScript ecosystem already depends on — it is what Fastify, AJV-backed OpenAPI tooling and countless CI pipelines use under the hood. Because it runs with allErrors turned on, you get the complete list of problems in one pass rather than the first failure, which is the difference between one edit and six. And because everything happens in your browser, the payload you are debugging — often a real order, a real customer, a real webhook body — never leaves your machine.

The workflow is deliberately plain. Put the document in the large pane, the schema in the smaller one below it, and press Validate. A conforming document reports the draft that was used, a zero error count, and a census of the nodes that were checked. A non-conforming one reports each violation on its own line, sorted by path, in the form #/path — message (keyword). Switch the Output option to JSON when you want the raw Ajv error objects instead — params and all — to paste into a test fixture or an issue.

If you do not have a schema yet, generate a starting point from a sample payload with the JSON to JSON Schema converter and tighten it by hand, or read the JSON Schema tutorial for a walkthrough of the vocabulary. If the document will not parse at all, fix that first in the JSON Formatter, which points at the offending line.

The keywords a schema actually checks

JSON Schema has a large vocabulary, but a working schema is usually built from a dozen keywords. The table below covers the ones that appear in almost every real schema, what each one asserts, and the shape it takes in the schema document. Keywords are constraints, not declarations: a value is valid unless a keyword says otherwise, which is why an empty schema — {} — accepts absolutely anything, and why forgetting required is the single most common reason a broken payload sails through validation.

Two behaviours are worth internalising because they cause most of the surprise. First, type checks are strict about numbers versus strings: "2" is not 2, and integer rejects 2.5 while number accepts it. Second, required lists property names at the level of the object that owns them — it is not a flag you put inside each property — so a nested object needs its own required array to protect its own fields.

Worked example: two rules, two errors

Here is the smallest schema worth writing: an object with an integer id and a status drawn from a fixed list, both required. It is the shape of half the records in any system — an identifier plus a state machine.

The document below parses without complaint. Nothing about it is malformed JSON. But the id arrived as a quoted string, which happens constantly when an identifier passes through a URL, a form field or a spreadsheet, and the status is a value that is not in the allowed set — a real bug, the kind that surfaces two services downstream when a switch statement falls through.

Validating one against the other produces exactly two lines, sorted by path. Read each one as: this location — this complaint (this keyword). The first says the value at #/id is not an integer; "42" is a string, and JSON Schema does not coerce. The second says the value at #/status is not in the enum, so either the payload is wrong or the schema needs "archived" added to its list — the validator tells you the rule that fired and leaves that judgement to you.

Note what is not reported: nothing about the missing properties, because none are missing, and nothing about extra keys, because the schema does not set additionalProperties: false. Both would be additional lines if the rules asked for them.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": [
    "id",
    "status"
  ],
  "properties": {
    "id": {
      "type": "integer"
    },
    "status": {
      "type": "string",
      "enum": [
        "open",
        "closed"
      ]
    }
  }
}

{
  "id": "42",
  "status": "archived"
}

✗ Invalid — 2 errors

Draft         draft-07
Data nodes    3 (1 object, 0 arrays, 2 values)

#/id — must be integer (type)
#/status — must be equal to one of the allowed values (enum)

Reading the report: paths, keywords and drafts

The header of every report names the draft that was used and the size of the document that was checked, so you can confirm at a glance that your 2020-12 schema was not quietly compiled as draft-07. The node census — objects, arrays and scalar values — is a sanity check on the data pane: if you expected a hundred line items and it says four, you pasted the wrong payload.

Below the header, one line per violation. The path is a JSON Pointer, so #/items/2/qty reads as "the qty of the third element of items", and a bare # means the whole document failed. The keyword in brackets is the rule that fired, which is what you search for in your schema. Errors are sorted by path rather than by the order Ajv found them, which groups everything wrong with the same node together and makes long reports scannable.

One asymmetry catches everyone: a missing property is reported on its parent, not on itself, because the missing value has no path. So a line item without a sku appears as #/items/2 — must have required property 'sku' (required), not as #/items/2/sku. Type errors, enum errors and bounds errors all report on the value itself.

When you need more than the message — the allowed values of an enum, the limit a number exceeded, the pattern a string missed — switch the Output option to JSON. The report then appends the normalised error objects, each with its path, keyword, message and Ajv's params object, ready to paste into a test or an issue. That is also the form to keep if you plan to feed the result into another tool: explore it as a tree in the JSON Viewer, or reindent it with the JSON Formatter.