10 Common Reasons JSON.parse Fails (and How to Fix Each One)

Every developer knows the moment: an API hands you a blob of JSON, the parser throws back a terse Unexpected token or Unexpected end of JSON input, and you’re left staring at a wall of text with no idea where it broke. JSON’s grammar is genuinely simple — but it’s also strict, so a single typo anywhere makes the whole document unparseable. Here are the ten syntax errors that cause the vast majority of real-world JSON.parse failures, each with a broken example and the fix, so you can stop guessing next time.

1. Unquoted Keys

JSON requires every key to be wrapped in double quotes. This trips people up constantly because JavaScript object literals don’t share the rule — {name: "Tom"} is perfectly valid JS, but as JSON it’s garbage:

{ name: "Tom", "age": 30 }

The fix is to quote every key: { "name": "Tom", "age": 30 }. Watch for this whenever someone copies a “JSON” snippet straight out of JavaScript source code.

2. Single-Quoted Strings

JSON only accepts double quotes. 'hello' is not a valid JSON string; it has to be "hello". You’ll see this a lot with data pasted from Python — repr() and print() render dicts with single quotes, and the output looks almost right until the parser chokes. The reliable fix is to produce JSON with json.dumps() instead of copying printed output.

3. Trailing Commas

This is the single most common JSON error, by a wide margin:

{
  "name": "Tom",
  "age": 30,
}

The last element of an object or array must not be followed by a comma. JavaScript, Python, and modern TypeScript all happily allow trailing commas, which is why they keep sneaking into JSON. Delete the comma after the final element. Note that JSON5 and JSONC (VS Code’s config format) do allow trailing commas — but a standard parser never will.

4. Comments

Standard JSON supports no comments whatsoever. //, /* */, and # all break parsing. Developers love annotating config files, and that works fine in JSONC — but not in a string headed for JSON.parse. If your data came from a config file, check whether whatever read it strips comments first.

5. NaN, Infinity, and undefined

Valid JSON values are exactly: string, number, boolean, null, object, array. NaN, Infinity, and undefined are not on the list. A backend that serializes a structure containing NaN will emit output no standards-compliant parser can read. Replace these values with null (or a string sentinel) before serialization.

6. Unescaped Quotes and Raw Newlines

A double quote inside a string must be backslash-escaped: "He said \"hi\"". Literal newlines are likewise forbidden inside strings — they must be written as \n. When JSON is copy-pasted through terminals, logs, or chat apps, escape sequences often get mangled or eaten, producing errors that look mysterious until you notice the missing backslash. Pasting the payload into a formatter makes the break point obvious within seconds.

7. The Invisible BOM

Some editors save UTF-8 files with a byte order mark — three invisible bytes (EF BB BF) at the very start of the file. You can’t see it, but a strict parser sees Unexpected token right at position zero. If a JSON file looks perfectly valid yet refuses to parse, inspect the first bytes with a hex viewer or run file on it, and strip the BOM.

8. Malformed Numbers

JSON numbers can’t have leading zeros (01 is invalid), can’t be hexadecimal (0x1F is invalid), and can’t omit the integer part (.5 is invalid — write 0.5). And if your “number” is actually an ID, phone number, or serial code, it should be stored as a string anyway — leading zeros and long digit sequences are both data-modeling hints, not just syntax problems.

9. Truncated Input: “Unexpected end of JSON input”

This message almost always means the document was cut short — a missing closing brace, bracket, or quote. Typical causes are an interrupted network transfer or a copy-paste that dropped the tail of the document. Throw the content into a formatter and you’ll usually see immediately where the structure stops making sense.

10. The Response Isn’t JSON at All

Sometimes an endpoint returns an HTML error page or plain text when something goes wrong upstream, while the client still calls JSON.parse on the body. The result is the classic Unexpected token < in JSON. The first character of the error message is your clue: < means HTML came back. Log the raw response before you parse it — it’s far faster than staring at the parse error.

A Fast Triage Workflow

When a JSON parse fails, work through these steps in order. First, paste the full payload into the JSON Formatter — it highlights the first syntax error, and most problems are solved right there. Second, if the data is deeply nested and the structural issue isn’t visible, open it in the JSON Visualizer to expand it into a tree and walk it level by level. Third, if the error message names an offending character, match it against the list above.

And one habit that prevents half of these errors entirely: always serialize and deserialize with a standard library. Hand-concatenated JSON strings are the common root cause of quoting, escaping, and comma bugs — let JSON.stringify do the work. If you eventually need to move that data into a spreadsheet, the JSON to CSV converter can flatten it once it’s clean.