Fix JSON Unexpected Token Errors
Why JSON.parse throws "Unexpected token" or "Unexpected end of JSON input", the six usual causes, and how to find the exact character that breaks it.
JSON.parse failures all look alike: Unexpected token } in JSON at position 41, Unexpected end of JSON input, or in Firefox JSON.parse: unexpected character at line 1 column 2. The message names the character the parser stopped on, not the mistake that put it there, which is why it is easy to stare at the wrong spot.
The fastest route is to paste the text into the JSON formatter below and read the position it reports. The rest of this article explains what you will find.
JSON FormatterPaste JSON to indent it readably and check that it parses, with the line and column of any error and a collapsible tree for finding your way around an unfamiliar response.The six usual causes
JSON is much stricter than a JavaScript object literal. Almost every parse error is one of these.
1. A trailing comma
{ "name": "Ada", "role": "engineer", }
JavaScript tolerates the comma after the last property; JSON does not. The parser reports the closing } as the unexpected token, because that is where it expected another key.
2. Single quotes
{ 'name': 'Ada' }
Strings and keys must use double quotes. Single quotes make the parser fail on the very first character.
3. Unquoted keys
{ name: "Ada" }
This is valid JavaScript and invalid JSON. Every key needs double quotes.
4. Comments
JSON has no comment syntax. A // or /* */ anywhere in the document is an error. Config formats that allow comments, such as JSONC, are a different format and need their own parser.
5. Values JSON does not have
undefined, NaN, Infinity and functions are not JSON values. JSON.stringify quietly drops undefined properties and turns NaN into null, so the problem often appears when hand-written or logged output is parsed back.
6. The text is not JSON at all
Unexpected token '<' almost always means an HTML page was parsed as JSON, typically an error page or login redirect returned by an API. Log the raw response text before you parse it and the real cause is usually obvious.
Smaller traps
- A byte order mark. Some editors write an invisible U+FEFF at the start of a file. It is reported as an unexpected token at position 0 even though nothing looks wrong.
- Unescaped control characters. A raw newline or tab inside a string must be written as
\nor\t. - Large numbers.
9007199254740993parses, but JavaScript rounds it to the nearest representable number. IDs this large are safer as strings. - Duplicate keys. They are not a syntax error, but most parsers keep only the last one.
A reliable debugging routine
- Print the raw string you are about to parse and confirm it begins with
{or[. - Paste it into a formatter and note the line and column of the first error.
- Fix that one error and re-check; the parser stops at the first problem, so another may be hiding behind it.
- If you are comparing a working and a broken payload, a JSON diff shows the difference faster than reading both.
