Common JSON Parse Errors and Fixes

JSON parse errors occur when a JSON parser encounters text that does not conform to the JSON grammar. These errors halt parsing completely — there is no partial result. Understanding the most common error patterns and their solutions is essential for every developer who works with JSON data.

"Unexpected token" errors:

This is the most common JSON parse error. It means the parser found a character where it did not expect one. Common causes include:

• Trailing commas: {"a": 1,} — the parser expects a key after the comma but finds }
• Single quotes: {'a': 1} — the parser expects " but finds '
• Unquoted keys: {a: 1} — the parser expects " but finds a
• Comments: {"a": 1 // note} — the parser does not recognize //
• Leading BOM: An invisible byte-order mark (U+FEFF) at the start of the file

"Unterminated string" errors:

This occurs when a string is opened with " but never properly closed. Common causes are unescaped quotes within the string ("She said "hello"" should be "She said \"hello\"") or literal newlines within a string (use \n instead).

"Unexpected end of input" errors:

The parser reached the end of the text while still expecting more content. This usually means a missing closing bracket ], brace }, or quote ". It can also happen when the input is completely empty.

Number format errors:

JSON is strict about number formatting. Leading zeros (007), leading plus signs (+5), bare decimal points (.5), hexadecimal (0xFF), octal (0o77), NaN, and Infinity are all invalid. Use 0.5 instead of .5, and represent special numeric concepts as strings or null.

Encoding issues:

JSON must be encoded in UTF-8 (recommended), UTF-16, or UTF-32. Files saved in other encodings like Latin-1 or Windows-1252 may contain byte sequences that are invalid UTF-8, causing parse errors on characters like é, ñ, or ü. Always save JSON files as UTF-8 without BOM.

Common mistakes developers make:

Developers often try to debug parse errors by staring at the JSON text, which is difficult with large documents. Instead, use a JSON validator that provides line and column numbers. Another mistake is catching the parse error but logging a generic "invalid JSON" message without including the original error details, making debugging impossible for the next person. Developers also sometimes confuse the error position — the reported location is where the parser gave up, not necessarily where the actual mistake is. The real problem is often several lines earlier.

Best practices:

Always wrap JSON.parse() in a try/catch block and provide the specific error message to the user or logs. Use editors with real-time JSON validation to catch errors as you type. When generating JSON programmatically, always use built-in serialization functions rather than string concatenation.