How to validate JSON

Syntax validation

Syntax validation asks whether the text obeys the JSON grammar. It is a yes or no answer, and a useful validator tells you where the no happened: the line, the column, the characters around it, what it expected and what it found.

A validator that only says "Unexpected token" has told you almost nothing about a 4,000-line file.

Line 14, column 3
Expected a property name in double quotes, found "}".
Near:  "qty": 2, }
Hint:  Remove the comma after the last property.

Structural warnings

Some things are valid but almost certainly wrong. Duplicate keys are the main one: {"a":1,"a":2} parses fine and quietly discards a value. Extreme nesting depth is another — a document 200 levels deep is legal but will hit limits in some parsers and serialisers.

These are warnings, not errors. A validator should surface them and let you decide.

Schema validation

Schema validation asks a different question: does this document have the fields, types and constraints it is supposed to have. A payload can be perfectly valid JSON and still be missing a required field, carry a string where a number belongs, or hold an email address that is not an email address.

JSON Schema is the standard for describing that shape. You write (or generate) a schema, then validate documents against it. Errors come back as a path into the document plus what failed — "/items/2/qty must be integer" rather than "invalid".

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id":    { "type": "integer", "minimum": 1 },
    "email": { "type": "string", "format": "email" },
    "tags":  { "type": "array", "items": { "type": "string" } }
  }
}

Generating a schema instead of writing one

Writing a schema for an existing API by hand is slow and produces omissions. Inferring one from a real response is faster and gets the shape right, because the response is the specification that actually matters.

Treat the generated schema as a first draft. Inference can only see one sample: it cannot know that a field is optional if it happened to be present, or that a string is really an enum. Feed it a representative payload, then tighten the result by hand.

Validate before you repair

If a document does not parse, find out why before running an automatic repair. Repair rewrites the text — it quotes bare keys, converts single quotes, drops trailing commas — and while that is usually right, it is a guess. Read the error first, and compare the repaired output against the original before you accept it.