5 JSON errors that break your data (and how to spot them)

JSON looks forgiving. It’s not. The spec (RFC 8259) is small and strict, and most of the errors that break a parser are variations of a handful of mistakes. If you’ve ever pasted JSON into a validator and stared at a wall of red, this list is what you’re fighting.

1. Missing commas

The most common error in hand-written JSON:

{ "name": "Ada"
  "role": "engineer" }

A parser sees the end of the string "Ada" and expects a : or , — and fails on the next character. The fix is a comma after every value except the last in an array or object. This is also where JSON differs from JavaScript object literals, which tolerate a lot more.

2. Trailing commas

{ "name": "Ada", "role": "engineer", }

JavaScript accepts this. JSON does not. A trailing comma after the last element is a parse error in strict JSON — many web APIs, formatters, and validators will reject it. Config files that allow trailing commas (like modern JSONC) are a different story, but a strictly validating parser will fail.

3. Single quotes and unquoted keys

{ name: 'Ada' }

That’s a JavaScript object literal, not JSON. JSON requires double quotes around every key and every string value. Single quotes, backticks, and bare identifiers are all invalid. This trips people who hand-write JSON the way they’d write JS, or who copy from logs that display keys without quotes.

4. Duplicate keys

{ "id": 1, "name": "Ada", "id": 2 }

This parses fine — and that’s the trap. RFC 8259 explicitly says behavior for duplicate keys is unpredictable: the parser may keep the first, the last, or throw an error. Different languages do different things. Two identical keys usually mean a merge bug upstream, and a good validator flags it rather than silently picking one.

5. Truncation and encoding artifacts

A file cut off mid-way, a log line split across two entries, or content mangled by an encoding handoff. These produce errors that look confusing: an unclosed brace, a � character where a quote should be, or a “unexpected end of input” error on a string that looks complete.

Related but distinct: numbers like NaN or Infinity (invalid in JSON — only null and finite numbers are allowed) and control characters in strings.

How to find them fast

You don’t have to debug these by eye. Paste the payload into a JSON validator and read the first error — line and character pointing at the exact spot. Validators differ from formatters here: a formatter may refuse with a cryptic error, while a good validator tells you what’s wrong at where it went wrong.

If the JSON is beyond repair, a JSON repair tool can fix the mechanical mistakes automatically — trailing commas, single quotes, missing braces. But repair has limits, and it can’t invent data that was truncated away. For anything that looks like a truncated file, go back to the source and re-export.

The 30-second checklist

• Commas after every value except the last?
• No trailing comma?
• Double quotes everywhere, on keys and strings?
• No duplicate keys?
• No NaN/Infinity/stray control characters?
• Complete, not truncated?

Get those six right and your JSON parses. Get one wrong, and the error message you get will make it obvious which.