Fixing invalid JSON: the eight errors that cause most failures

JSON has a small specification and no tolerance. A document is either valid or it is rejected, and the parser stops at the first problem with a message that points at where it gave up rather than at what you did wrong. These are the errors that account for most failures, in rough order of how often they appear.

1. A trailing comma

The single most common cause. JavaScript object literals allow a comma after the last item; JSON does not.

{
  "name": "Ada",
  "role": "admin",     ← this comma is the error
}

The reported position is the closing brace, one character after the real mistake, which is why the message can look confusing. Whenever an error points at a } or ], look at the line above it.

2. Single quotes

JSON strings must use double quotes, for both keys and values. {'name': 'Ada'} is valid JavaScript and invalid JSON. The parser fails at the first quote character, reporting an unexpected token.

3. Unquoted keys

Every key must be a quoted string. {name: "Ada"} is rejected, again at the very first character of the key.

4. Comments

JSON has no comment syntax. Neither // nor /* */ is permitted, which regularly surprises people editing configuration files. Some tools accept a relaxed dialect — JSONC or JSON5 — but a strict parser will refuse. If you need to annotate a config, add a "_comment" key, which is ugly and valid.

5. Unescaped characters inside strings

A literal newline, tab or unescaped double quote inside a string breaks it. They have to be written as escapes:

"He said \"hello\"\nand left."

Backslashes need doubling too, which is why Windows paths are such a frequent source of invalid JSON: "C:\\Users\\ada".

6. NaN, Infinity and undefined

None of these exist in JSON. They appear when a program serialises a floating-point calculation that went wrong, or a JavaScript value that was never set. Seeing NaN in a payload usually means there is a bug upstream in whatever produced it, so fixing the JSON by hand treats the symptom.

7. A leading byte order mark

A file saved by some Windows editors begins with an invisible byte order mark. The document looks perfect and the parser reports an unexpected token at position 0. Re-save as UTF-8 without a BOM.

8. Large integers losing precision

This one does not throw an error, which makes it worse. JavaScript numbers are IEEE 754 doubles, so integers above 9,007,199,254,740,991 cannot be represented exactly. An identifier such as 9007199254740993 silently becomes 9007199254740992 when parsed and re-serialised. The document stays valid and the value is wrong.

The fix is at the design stage: transmit 64-bit identifiers as strings. Snowflake IDs, database bigints and financial values in minor units all belong in quotes.

Two more that pass validation but still bite

Duplicate keys

The specification does not forbid them and most parsers keep the last occurrence. A document with two "id" keys is valid JSON and almost certainly not what anyone intended.

Key order

Object key order carries no meaning in JSON, but text-based comparison tools treat a reordering as a difference. That is worth remembering when two payloads look completely different in a diff and contain identical data.

A working method

1. Paste the document into the JSON formatter and read the error message and position.
2. Look at the line before the reported position, because the parser reports where it stopped rather than where the mistake is.
3. Fix one problem, then re-check. Errors mask each other.
4. Once it parses, format it. Indentation makes structural mistakes such as a missing closing bracket visible.
5. If you are comparing two payloads, use the JSON comparison tool rather than reading them side by side.

If you are consuming an API and want types rather than guesswork, a validated sample can be turned into TypeScript interfaces with the JSON to TypeScript converter. Remember that a single sample cannot tell you which fields are optional, so mark those yourself.