JSON Validator

What validating JSON tells you

A JSON document is either accepted by a parser or it is not, and if it is not, exactly one thing needs to happen: you find the character that broke it. That part is easy. The harder and more common problem is a document that parses perfectly and still is not what you expected, which is why this page reports more than a verdict.

For valid input you get:

• The root type. An API that returned an array when your code expects an object is a five-minute bug that looks like a one-hour bug.
• Size and depth. The number of items at the top level, the total key count, and how deeply the document nests.
• Duplicate keys. Covered below, because it is the one thing here that no amount of reading the parsed output will reveal.

Duplicate keys: valid, and silently lossy

This is legal JSON, and every parser accepts it:

{
  "retries": 3,
  "timeout": 30,
  "retries": 5
}

The specification permits an object to repeat a key and leaves the outcome to the implementation. In practice every mainstream parser keeps the last one, so the object above becomes { retries: 5, timeout: 30 }. No error is raised, nothing is logged, and the first value is simply gone.

That is a real cause of the worst kind of configuration bug: the file plainly says 3 on the line you are looking at, and the service behaves as though it said 5. It usually happens when two people edit a config file, or when a find-and-replace adds a key that already existed further down.

Because the information is destroyed at parse time, a validator that only calls JSON.parse cannot possibly report it. This one scans the source text, so it can. Load the sample above to see it in action.

How to read the error

When parsing fails you get a sentence, a line and column, and the browser's original message behind a toggle. The sentence is worth trusting more than the raw message, because engines report the point where the parser gave up rather than the point where you made the mistake, and their wording is inconsistent even within a single browser version.

A concrete example: for [1, 2, ] Chrome reports Unexpected token ']' with no position at all, while for {"a": 1,} it reports Expected double-quoted property name with a position. Both are the same mistake: a trailing comma. This page says so, and names the line.

Common use cases

• Checking a config file after a merge, where duplicate keys are most likely to appear.
• Confirming the shape of an API response before writing code against it: array or object, how many items, how deep.
• Verifying that a payload built by string concatenation or a template actually produces valid JSON.
• Finding the broken line in a file your editor only marks with a red squiggle.

What this does not check

Only syntax and structure. It does not validate against a JSON Schema, so it cannot tell you that timeout should be a number rather than a string, or that a required field is missing. If you need that, a schema validator is the right tool. It also does not check semantics: a valid document full of wrong values is still valid.

To reformat a document once it is valid, use the JSON Formatter. To shrink it for transport, use the JSON Minifier.

Privacy

Validation happens in your browser. The document is never uploaded, which matters here more than on most pages: the files people validate are usually configuration, and configuration usually contains credentials.