The 5 JSON Errors That Break Most Parsers

JSON was designed to be a strict subset of JavaScript object literals, but "strict subset" means a lot of things that are perfectly legal JavaScript are invalid JSON. Here are the five mistakes that cause almost every parse error.

1. Trailing commas

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

That comma after 30 is invalid. JavaScript allows a trailing comma in object and array literals; JSON's grammar does not. This is the single most common error, usually introduced by manually editing JSON that was copy-pasted from a JS source file.

2. Single quotes

{'name': 'Alice'}

JSON strings must use double quotes — full stop. Single quotes are valid in JS and in Python dicts, which is why this error shows up constantly when JSON is hand-written or converted from a Python print(dict) output rather than json.dumps().

3. Unquoted keys

{name: "Alice"}

Object keys must be quoted strings in JSON. {name: "Alice"} is valid JavaScript (bare identifier keys), but not valid JSON.

4. Unescaped control characters and quotes inside strings

A literal newline inside a string, or a double quote that isn't escaped with \", breaks the parser mid-string — everything after it gets read as if the string were still open, producing a confusing error far past the actual mistake. This is common when JSON is built by concatenating strings in code rather than through a proper serializer (JSON.stringify, json.dumps), since those escape correctly by construction.

5. NaN, Infinity, and undefined

{"result": NaN}

JSON.stringify(NaN) in JavaScript actually produces the string "null" — but hand-written or logged JSON sometimes has the literal token NaN or Infinity, which are valid JavaScript identifiers but not JSON values. JSON has no representation for "not a number" or infinite values; only null and finite numbers.

Why the error message points at the wrong line

Parsers read left to right and only know something's wrong once the grammar breaks — which is often several tokens after the actual mistake. A missing comma between two object properties won't fail until the parser hits the next key and finds two string tokens back-to-back where it expected a comma. So "line 47" in the error is really "where the parser gave up," not "where you made the mistake." When debugging, check a few lines before the reported position first.

The fastest way to find it

Pretty-printing consistently formatted JSON (2-space indent, one key per line) turns an error like "unexpected token at position 812" into something visually obvious — a dangling comma or a missing quote stands out immediately once every key is on its own line. Spellkit's JSON Formatter does exactly this, plus reports the line and column of the syntax error directly, entirely in your browser.