Why is my JSON invalid when it looks perfectly fine?

JSON looks like a JavaScript object, which is exactly why it trips people up. It is a subset of JavaScript object syntax, and the things it leaves out are precisely the conveniences you are used to.

Four mistakes cause the overwhelming majority of parse failures. Here they are, in descending order of how often they catch people.

1. The trailing comma

This is the most common by a wide margin, because modern JavaScript permits it and most editors will not flag it.

A comma after the final item in an object or array is valid JavaScript. It is not valid JSON. The specification permits commas only between elements.

It usually appears when you delete the last property from a hand-edited config file and forget to remove the comma from the line above it. The error message you get, typically something about an unexpected token, points at the closing brace, not the comma.

2. Single quotes

JavaScript treats 'value' and "value" as equivalent. JSON does not. Every string in JSON must use double quotes, without exception. This catches people constantly when copying object literals out of JavaScript source.

The same applies to keys, which brings us to the third mistake.

3. Unquoted keys

In JavaScript you can write {name: "Ada"}. In JSON the key must be quoted: {"name": "Ada"}. Always, even when the key is a simple identifier with no spaces or special characters.

This is the difference that most often reveals someone has pasted a JavaScript object where JSON was expected. If your data came out of a console.log, it is almost certainly a JavaScript object literal rather than JSON, and will need both the quotes fixed and any trailing commas removed.

4. Unescaped characters inside strings

A literal newline inside a JSON string is invalid, it must be written as \n. The same applies to tabs, and to double quotes and backslashes appearing inside a string.

This one is nastier than the others because the offending character is often invisible. Text pasted from a word processor frequently contains non-breaking spaces or smart quotes; text pasted from a terminal may contain control characters. The file looks correct and will not parse.

Why the error points at the wrong line

This deserves its own section because it wastes so much time.

A parser reports where it gave up, not where you made the mistake. Those are frequently different places. If you forget a comma at the end of line 8, the parser reads line 8 successfully, moves to line 9, and only then discovers it was expecting a comma or a closing brace. It reports an error on line 9.

So when a JSON error points at a line that looks perfectly fine, check the line above it. That habit alone will resolve a large fraction of these.

Things JSON does not have

Beyond the four mistakes, a set of things people reasonably expect and do not get:

• Comments. Neither // nor /* */. This was a deliberate decision by Douglas Crockford, who removed them because people were using them to carry parsing directives.
• Undefined. There is null, and nothing else. A JavaScript property set to undefined simply vanishes when serialised.
• NaN and Infinity. Not representable. JSON.stringify turns them into null, silently.
• Dates. No date type. Dates become ISO 8601 strings and must be parsed back manually, a round trip does not restore a Date object.
• Trailing decimals. 1. and .5 are both invalid; write 1.0 and 0.5.

The variants that fix some of this

Several relaxed dialects exist, and it is worth knowing they are not JSON:

If a file with comments parses fine in VS Code but fails in your program, this is why: it is JSONC, and a standard JSON parser will reject it.

One security note

If you are parsing JSON from an untrusted source, use JSON.parse and never eval. This should go without saying, but code that predates JSON.parse being universally available still circulates, and eval on attacker-controlled input executes arbitrary code.

How to debug invalid JSON systematically

When a parser rejects your JSON, the error message almost always names a line and column, and that pointer is the fastest route to the fix. Start there rather than scanning the whole document. The parser reports the point where it first got confused, which is usually at or just after the real mistake, a missing comma on the previous line, for instance, is often flagged at the start of the next one. Reading the character immediately before the reported position resolves a large share of errors on its own.

For anything larger than a few lines, paste the document into a formatter that validates as it pretty-prints. Formatting collapses the two most common problems into plain sight: mismatched brackets become obvious once the structure is indented, and a value that is not properly quoted stands out against its neighbours. If the JSON is genuinely large, validate progressively, comment out or remove sections until it parses, then reintroduce them until it breaks again, which isolates the offending block quickly.

Also be aware that JSON.parse will happily parse deeply nested structures until it exhausts the stack. If you are accepting JSON from users, cap the payload size before parsing rather than after.