A validator that only says “unexpected token” has told you where it gave up, not what you did wrong. Those are often different places. A missing comma is usually reported at the next token, not at the missing comma itself, and an unclosed bracket is reported at the end of the file no matter which line opened it.
What the JSON validator reports
Paste a document and press Validate, or just stop typing since validation
runs automatically. The result names the actual construct that is wrong:
single quotes, an unquoted key, a trailing comma, a wrong case keyword like
True or NULL, NaN or Infinity, a leading zero, or a bad escape
sequence, each with the line and column where it starts.
Duplicate keys, which most validators say nothing about
A duplicate key is legal JSON. The specification permits it, and every parser you are likely to use keeps the last value and silently discards the earlier one. That means data can disappear from a document that is perfectly valid, with no error anywhere. Paste
{"region":"eu-west-1","retries":3,"region":"us-east-1"}and the validator reports it as valid JSON, one line, and separately warns:
Duplicate key “region”. The last value wins, the earlier one on line 1 is discarded.
That is a warning, not an error, because the specification really does allow it. But it is the kind of bug that is invisible until something downstream reads the wrong value, and most tools never mention it.
What counts as an error versus a warning
An error means the document is not valid JSON and nothing downstream should try to parse it: a syntax problem, an illegal character, a structural mistake. A warning means the document parses, but something about it is worth a second look, such as a duplicate key. The status line at the top tells you which one you are looking at, and errors mark the failing line in the editor gutter so you can find it without scrolling.
Why this matters before you commit or deploy
Config files, API fixtures and generated data all pass through a JSON parser eventually, usually in production, where the error message is whatever the runtime’s default parser gives you. Catching a trailing comma or a duplicate key here, with a message that names the mistake, is faster than debugging the same problem after a deploy.