Common JSON Errors and How to Fix Them

JSON's syntax is small, which makes it easy to learn and brutal when you get one character wrong. Here are the errors that come up constantly, what actually causes each one, and how to fix it — not just what the cryptic parser message means, but what to actually look for in your document.

Trailing commas

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

That comma after 30 is invalid. Unlike JavaScript object literals (where a trailing comma is completely fine), strict JSON does not allow a comma after the last item in an object or array. This is probably the single most common JSON error, because it's exactly the kind of thing your eye skips right past. Fix: remove the comma after the final key-value pair or the final array item.

Single quotes instead of double quotes

{ 'name': 'Alice' }

JSON requires double quotes for strings and keys — always. Single quotes are valid in JavaScript object literals and in Python dictionaries, which is exactly why this mistake is so common: people write JSON the way they'd write an object in whichever language they use most. Fix: replace every single quote used for a string or key with a double quote.

Unquoted keys

{ name: "Alice" }

In JavaScript, object keys don't need quotes if they're valid identifiers. In JSON, every key must be a quoted string, no exceptions. Fix: wrap every key in double quotes: { "name": "Alice" }.

Using JavaScript's undefined

{ "middleName": undefined }

undefined isn't a JSON value at all — it's a JavaScript-only concept. JSON has exactly four scalar value types plus objects and arrays: string, number, boolean, and null. Fix: use null to represent "no value," or omit the key entirely if that fits your API's convention better.

Comments

{
  // this is the user's name
  "name": "Alice"
}

Standard JSON has no comment syntax whatsoever, in any form. This trips people up constantly because JSON looks so close to JavaScript, where comments are completely normal. Fix: remove the comment entirely. If you genuinely need comments in a config file, that's a sign you may want a format that supports them, like YAML, or a JSON-superset dialect like JSONC, if your specific tool supports it.

Unescaped special characters inside strings

{ "quote": "She said "hello" to me" }

That inner pair of unescaped double quotes ends the string early as far as the parser is concerned, and everything after it becomes invalid syntax. Fix: escape internal double quotes with a backslash: "She said \"hello\" to me". The same applies to literal backslashes (escape as \\) and raw newline characters inside a string (escape as \n).

Leading zeros on numbers

{ "code": 007 }

JSON numbers can't have leading zeros (except the number zero itself). This one surprises people because it looks so harmless. Fix: if it's genuinely a numeric value, drop the leading zero (7). If the leading zero actually matters — like a ZIP code or an ID with meaningful padding — store it as a string instead: "code": "007".

Mismatched brackets and braces

{
  "tags": ["a", "b", "c"}
}

The array was opened with [ but closed with } instead of ]. This usually happens during manual editing — deleting or copy-pasting part of a document and losing track of which bracket belongs to which pair. Fix: a good formatter (or a code editor with bracket matching) will usually make the mismatch immediately visible; make sure every { closes with } and every [ closes with ], in the right order.

NaN and Infinity

{ "result": NaN }

NaN and Infinity are valid values in JavaScript but not in JSON — the JSON spec only allows finite numbers. This typically shows up when serializing the result of a division by zero or another invalid math operation without checking for it first. Fix: convert these to null or a string representation before serializing, and handle the invalid-math case in your application logic rather than letting it leak into the JSON.

Reading the parser's error message

Most JSON parsers report a line and column number, or a character position, for where parsing failed. That position is usually close to, but not always exactly at, the actual mistake — a missing comma, for instance, often gets reported at the start of the next value, not at the missing comma itself, because that's the point where the parser's expectations were first violated. When a formatter or validator gives you an error, check the reported line and the line just before it.

Frequently Asked Questions