“Unexpected token in JSON” is probably the most-Googled parse error in web development. The message is unhelpful because the parser reports where it gave up, not what you meant. Here are the seven causes behind nearly every occurrence, each with its fix.
1. Trailing commas
{"a": 1,} — arrays and objects may not end with a comma in JSON. JavaScript objects allow it (ES2017), which is exactly why this error follows code copied from JS source into an API payload or config file. Fix: delete the comma before the closing bracket.
2. Single quotes
{'a': 1} — JSON strings and keys require double quotes, always. Single-quoted objects are valid JavaScript but not valid JSON. Fix: replace quotes; when the payload comes from a JS literal, run it through JSON.stringify to convert properly (it also handles escapes correctly).
3. Unescaped line breaks inside strings
{"text": "line one
line two"}A string literal cannot contain a raw newline. Fix: escape it as \n, or — if the content comes from real multiline data — put the whole string through a JSON escape pass before embedding.
4. Comments
{ /* config */ "a": 1 } — JSON has no comment syntax, by design (Douglas Crockford removed them to make the format parseable as a data format). Config formats that need comments use YAML, TOML, or JSON5. If a tool requires strict JSON, move comments to a _comment key or sidecar documentation.
5. Smart quotes
{"a": "smart"} where the inner quotes are U+201C/U+201D — these come from copying code through word processors, Slack, or some chat clients that auto-prettify. They look identical in most fonts; the parser sees garbage. Fix: retype the quotes in an editor, or paste through the JSON formatter, which flags the offending byte.
6. BOM at the start of the file
A UTF-8 BOM (EF BB BF) before { produces “Unexpected token ” pointing at byte 0. Common when config files are saved by Windows editors. Fix: re-save as UTF-8 without BOM.
7. One JSON value per line, violated
For JSON Lines / NDJSON data, a pretty-printed object spanning multiple lines is actually multiple parse errors — each line must be a complete value on its own. Fix: minify each object to a single line; the JSON Lines validator pinpoints the offending line and can convert a normal JSON array into valid JSONL.
The debugging habit that finds any of these
Read the error position, then look at the previous token, not the position itself: parsers fail one character after the actual mistake. A validator that shows line and column — like the JSON Formatter, which runs entirely in your browser so payloads with sensitive data never leave the machine — turns each of these seven from a ten-minute hunt into a ten-second fix.