The six JSON mistakes that cause almost every parse error

Unexpected end of JSON input

The single most common error, and the least obvious, because the parser is telling you that the document ended before it was finished. The usual causes are a truncated network response, a body that was cut off in a log, or a string that was closed early.

If the payload came from a network call, the first thing to check is the length. A response that is 1,024 bytes long when you expected 4,096 is a truncated response, not a malformed document.

// The parser points at the end because the document simply stops there.
{
  "id": 42,
  "name": "Ada"      <-- no closing brace

• Check whether the response was truncated in transit.
• Check whether a string contains an unescaped quote that closed it early.
• Check whether you are parsing a log line rather than the payload.

Trailing comma

A comma after the last item in an object or an array is not valid JSON, and it is the mistake that gets introduced most often, because it is legal in JavaScript, in Python and in most configuration formats.

The error position points at the comma, which is confusing, because the actual problem is the character after it. Look one character to the right of the reported position.

{
  "id": 42,
  "name": "Ada",     <-- this comma
}

Single quotes instead of double quotes

JSON requires double quotes around every string and every key. Single quotes are valid JavaScript, valid Python and valid YAML, which is exactly why they survive a copy-paste from a chat window or a Python dictionary.

The error usually appears on the very first quote, which is a useful signal: if a document starts with a single quote, the whole file is probably single-quoted.

Unquoted keys

JavaScript object literals do not need quotes around keys when they are valid identifiers, and neither does Python. JSON does. The parser reports the position of the key, which makes it easy to fix once you know what you are looking at.

{ id: 42, name: "Ada" }   // JavaScript
{ "id": 42, "name": "Ada" }   // JSON

Comments

JSON has no comment syntax, which is an old decision that JSONC, JSON5 and HJSON were invented to work around. If a file has `//` or `/* */` in it, it is one of those formats, and a strict JSON parser will reject it.

The practical fix is to strip the comments before parsing, which has to be done with a parser that understands strings, because a `//` inside a string is not a comment.

Smart quotes and invisible characters

A document that came out of a word processor, a chat application or a PDF can contain typographic quotation marks, a non-breaking space or a zero-width space. All of them are valid characters in a JSON string and none of them are what you meant.

The error position is a character in the middle of a key, and the character at that position is not the one on your screen. Replacing the smart quotes with straight ones usually fixes it, and the BOM at the start of a UTF-8 file exported from Windows is the same class of problem.

• `“` and `”` should be `"`
• The typographic single quotes `‘` and `’` become a straight ASCII apostrophe (U+0027)
• A zero-width space is invisible in most editors. A hex dump finds it.
• A byte order mark at the start of the file is a common cause of an error reported at position 0.