Why Your JSON Won't Parse: Every Common Syntax Error, Explained
JSON looks close enough to a JavaScript object literal that it's easy to assume anything valid in one is valid in the other. It isn't. JSON is a much stricter subset, on purpose — the spec was designed to be dead simple to parse in any language, not just JavaScript, which means it deliberately leaves out several things JS allows. Here's the specific list of what trips people up, in the order they actually show up in practice.
Trailing commas
This is the single most common one. {"a": 1, "b": 2,} is a completely normal JavaScript object literal — the trailing comma after the last property is explicitly allowed and often left in on purpose so future diffs stay clean. In JSON, that same trailing comma is a hard syntax error. The fix is just deleting it, but the trap is that it's invisible when you're eyeballing a large object — it's almost always caught by a parser, not a human proofreading.
Single-quoted strings
{'name': 'Ada'} is valid JavaScript, and invalid JSON. The JSON spec only recognizes double quotes for strings and keys — single quotes aren't a stylistic alternative, they're simply not part of the format at all. This one shows up most often when someone hand-writes a "JSON" example from memory, or copies a JS object literal without converting it.
Unquoted object keys
{name: "Ada"} — no quotes around name — is valid JavaScript shorthand. JSON requires every key to be a double-quoted string, no exceptions. This usually travels together with the single-quote mistake above, since both come from the same source: treating a JS object literal as if it were already JSON.
Missing commas between properties or array items
{"a": 1 "b": 2} — no comma between the two properties — is invalid in both JSON and JavaScript, but it's worth calling out separately because the resulting error message is often the least helpful of the bunch. Depending on the parser, you might see something like "Unexpected string" or "Expected ',' or '}'" pointing at the second key, which makes it look like the second property is the problem when the actual fix is adding a comma right before it.
Comments
JSON has no comment syntax at all — not //, not /* */. This is a deliberate spec decision, not an oversight: comments would need a defined behavior for how tools re-serialize data (do they preserve comments on write? discard them? where do they go if a key moves?), and the spec's author decided that ambiguity wasn't worth it. If you need comments in a config file, you're looking for a JSON superset like JSON5 or JSONC (which VS Code's own config files use) — or you strip the comments out before feeding the file to a strict JSON parser.
Duplicate keys — not an error, but still a bug
Unlike everything above, {"a": 1, "a": 2} is technically valid JSON — most parsers accept it and simply keep the last value (a ends up as 2), silently discarding the first. This is worth knowing specifically because it won't show up as a syntax error at all; if you're wondering why a value seems to have "disappeared" from a hand-edited JSON file, a duplicate key further down is a common, silent cause.
Catching these without guessing which one it is
The fastest way to find out which of the above is actually happening in a specific broken snippet is to let a real JSON parser tell you — the exact wording and, in most browsers, the line and column it points to are more reliable than scanning by eye, especially in a large nested object. FreeToolDev's bulk JSON validator runs each pasted snippet through the browser's own parser and shows the error location directly, and it accepts several snippets pasted at once if you're chasing more than one broken payload at a time.
FAQ
Why does JavaScript accept trailing commas and unquoted keys, but JSON doesn't?
JSON was deliberately specified as a minimal, language-independent data format — its grammar is intentionally smaller than a JavaScript object literal's, so that it stays trivially easy to implement a compliant parser in any language, not just JS. JavaScript's own object literal syntax was never constrained by that goal, so it kept the more permissive, human-friendly conveniences JSON left out.
Is JSON5 the same thing as JSON?
No — JSON5 is a separate, related format that intentionally adds back some of what JSON leaves out (comments, trailing commas, unquoted keys) for config-file use cases where those conveniences matter more than strict interoperability. A JSON5 file is not valid JSON, and a standard JSON.parse will reject it the same way it rejects any of the mistakes above.
Why don't duplicate keys throw an error?
The JSON spec doesn't actually forbid duplicate keys — it says behavior in that case is left to the implementation, and in practice essentially every parser (including JSON.parse) resolves it by keeping the last occurrence and silently ignoring earlier ones, rather than raising an error. That's a spec gap, not a bug in any particular parser.