Why Is My JSON Invalid? The Seven Usual Causes

Almost every invalid JSON document fails for one of seven reasons, and six of them share a single root cause: JSON looks like JavaScript, so people write JavaScript. The two are close relatives, and the differences are precisely the places a parser stops. Once you know the list, most parse errors become a two-second fix rather than a hunt.

A trailing comma after the last item

This is the most common failure by a wide margin. JavaScript has permitted a trailing comma in arrays and objects for years, and most linters actively encourage it because it keeps diffs clean. JSON never allowed it. The parser reaches the comma, expects another value, finds a closing brace instead, and gives up.

{
  "name": "ada",
  "role": "engineer",
}

                    ^ this comma is fatal

Single quotes instead of double

JSON strings must use double quotes. Not single quotes, not backticks, and not the curly typographic quotes that a word processor or a chat client will silently substitute for you. That last one is genuinely nasty, because the document looks correct on screen and the offending character is invisible in most editors.

Unquoted keys

In a JavaScript object literal, keys need quoting only when they are not valid identifiers. In JSON every key is a string and every string is double quoted, without exception. Anything pasted out of a source file, rather than out of a network response, is likely to trip on this.

Comments

JSON has no comments, by deliberate design rather than by oversight. They were removed specifically to stop people using them to carry parsing directives. Configuration dialects such as JSONC and JSON5 add them back, which is why a file that opens fine in your editor can still be rejected by a standard parser.

Undefined, NaN and Infinity

These are JavaScript values with no JSON equivalent, and writing them by hand produces a document nothing can read back. This is also the one case where the standard library will not warn you: stringify silently drops undefined properties instead of failing, so a value can vanish between writing and reading without a single error being raised.

The one that is not a syntax mistake at all

Sometimes the JSON is fine and the response was never JSON. A proxy returned an HTML error page, a login redirect fired, or the endpoint answered with an empty body. The clue is in the message: an error at position zero, or one complaining about a character that happens to open a tag, means you are trying to parse a web page.

If the parser complains about position 0, stop reading the JSON and look at what the server actually sent.

Reading the error position properly

Parser messages point at where parsing stopped, which is rarely where the mistake is. A missing closing brace on line four gets reported at the end of the file, because that is the first point at which the parser can be certain something is wrong. Work backwards from the reported position rather than staring at the line it names, and re-indent the document first — a structural mistake usually becomes obvious the moment the nesting is laid out properly.