How to Validate JSON

Being precise about this saves real time, because most arguments about whether a payload is "valid" are two people answering different questions.

The gap between the first two is where production incidents live. {"userId": "42", "email": null} is perfectly well-formed JSON. It is also an ID that arrived as a string when your code expects a number, and a null in a field marked required — and no JSON validator on earth will mention either.

RFC 8259 is only about the first level. It defines syntax; ECMA-404 says the same thing about itself in as many words. Nothing in the format has any opinion about which fields your API ought to return.

The quickest check is a parse: if a parser accepts it, it is valid JSON, and if it does not, the error tells you where.

Every mainstream language will validate JSON in one line, which is what you want for a file on a server or a step in a build.

Python needs nothing installed:

python -m json.tool file.json

It prints the formatted document on success and the error with a line and column on failure, and returns a non-zero exit status — which is what makes it usable in a script.

jq is the tool worth having if you handle JSON regularly. It validates, and it also streams, so it copes with files far larger than a browser tab will:

jq empty file.json

empty produces no output; the exit status is the answer. In Node, JSON.parse inside a try/catch is the whole story, and in CI a single step that parses every changed .json file will catch a malformed config before it ships. A pre-commit hook doing the same thing catches it before it is even committed.

A caution about that last one: do not build a validation step on a regular expression. JSON is a recursive grammar, so no regex can match it correctly, and a "JSON-ish" pattern will pass documents that no parser accepts. Use a parser; you have one in every language you already have installed.

Once syntax is settled, the useful question is whether the document has the shape both ends agreed on. That is what JSON Schema is for: a JSON document that describes the permitted shape of other JSON documents — required fields, types, string patterns, numeric ranges, enumerated values, nested object shapes.

A minimal example:

{
  "type": "object",
  "required": ["userId", "email"],
  "properties": {
    "userId": { "type": "integer" },
    "email":  { "type": "string", "format": "email" },
    "tags":   { "type": "array", "items": { "type": "string" } }
  }
}

Validate the earlier payload against that and you get real answers: userId is a string where an integer was required, and email is null where a string was required. Both were invisible to syntax validation.

Where this matters most is at a boundary you do not control — a webhook, a partner's API, a queue consumer. Schema validation at the edge turns "the data was wrong three services deep" into "the request was rejected with a reason".

ToolForge does not do schema validation, and it is worth saying so plainly. The schema visualizer infers the shape of a document you paste — types, nesting, which keys appear — which is genuinely useful for writing a schema or understanding an unfamiliar payload, but its own page is careful to note that it does not produce a formal JSON Schema document and does not validate against one. For actual validation, use a library: Ajv in JavaScript, jsonschema in Python, or whatever your framework already has. If your API is described by OpenAPI, you may have schemas already and not be enforcing them.

Validation gets discussed as a defensive measure against other people's data. Half its value is on the way out.

Three cases where checking your own output pays for itself:

Hand-written configuration. Anything a human edits — a feature-flag file, a seed dataset, a translations bundle — should be parsed by CI on every change. It is one step, and the failure it prevents is a deploy that breaks on startup.

Generated payloads. If you build JSON by string concatenation anywhere, you have a quoting bug waiting to happen: a customer with an apostrophe in their name, or a description containing a newline. Use your language's serialiser rather than templating, and if you must template, escape the values properly.

Fixtures in tests. A malformed fixture produces a test failure that looks like a code bug. Validating fixtures separately makes the difference obvious immediately.

For the specific case of "did this payload change", a validator is the wrong instrument entirely — comparing it structurally against a known-good version answers the question directly, and ignores reordered keys and reformatting while doing so.

Worth being blunt, because "the JSON is valid" gets used as though it settled something.

A well-formed, schema-conforming document can still be wrong in every way that matters. The timestamp can be in the wrong timezone. The amount can be in dollars where the consumer assumes cents. The ID can point at a record that was deleted. The producer can send recipentEmail where the contract said recipientEmail — and schema validation catches that one only if you marked the field required, which is exactly the case people forget.

Two format-level traps validation also misses, both covered in the syntax reference:

Duplicate keys. Legal JSON. Every parser accepts {"a": 1, "a": 2} and most keep the last value, so a document that silently lost half its data validates perfectly.

Numeric precision. A nineteen-digit identifier is a valid JSON number, and it is a rounded number by the time a JavaScript consumer sees it. The document is valid; the value is wrong.

Validation is a floor, not a guarantee. It tells you the message is a message. Whether it says what it should is a question for your tests.