JSON: The Four Mistakes That Cause Almost Every Parse Error

JSON is deliberately tiny. The entire grammar fits on a business card, which is exactly why it displaced XML for API payloads. But its resemblance to JavaScript object literals is a trap: JSON is a strict subset, and the things it leaves out are precisely the things developers reach for by habit.

Here are the four that cause almost every parse error, in roughly the order you will hit them.

1. Trailing commas

The single most common error.

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

That trailing comma after the last value is legal JavaScript, legal in most config formats, and invalid JSON. Every conforming parser rejects it.

It is particularly nasty because it usually appears while editing — you delete the last property and leave the comma behind. If a file parsed yesterday and does not today, check the last entry of every object and array first.

2. Single quotes

JSON requires double quotes. Both for keys and for string values.

{ 'name': 'Ada' }     ← invalid
{ "name": "Ada" }     ← valid

This one usually arrives when someone copies a JavaScript object out of their editor and expects it to be JSON. It looks right, and it is not.

3. Unquoted keys

{ name: "Ada" }       ← JavaScript object literal
{ "name": "Ada" }     ← JSON

In JavaScript, a key that is a valid identifier does not need quoting. In JSON, every key is a quoted string, without exception.

4. Comments

JSON has none. Not //, not /* */.

This is a genuine pain point for configuration files, and the reason several JSON supersets exist — JSON5, JSONC (used by VS Code), and HJSON all add comments back. But they are different formats. A standard parser given a commented file will fail.

The conventional workaround in strict JSON is a dummy key:

{
  "_comment": "rate limit is per-minute, not per-second",
  "rateLimit": 60
}

What JSON does not have

Beyond syntax, a few absences catch people out.

No date type. Dates are strings by convention, almost always ISO 8601 (2026-10-01T14:30:00Z). Your parser will hand you a string, not a Date. Every serialisation library has its own opinion about the format, which is a recurring source of cross-service bugs.

No integers, only numbers. JSON has one numeric type, defined as a double. Large integers lose precision: an ID like 9007199254740993 will not survive a round trip through most parsers. This genuinely breaks things — it is why Twitter's API has returned IDs as strings for years. If a value exceeds 2⁵³, transmit it as a string.

No NaN or Infinity. Both are valid JavaScript numbers and invalid JSON. Serialising them usually produces null, silently.

No trailing-comma tolerance, ever. There is no parser flag for it in the standard.

Formatting versus minifying

Whitespace between tokens carries no meaning in JSON, so the formatted and minified forms are identical to any parser. The choice is entirely about who is reading it.

Format for anything a human touches: configuration files, fixtures, seed data, anything in version control. A minified file produces a single-line diff for every change, which makes code review essentially impossible.

Minify for anything transmitted or stored at volume. On a large payload it typically saves 15–30%.

One caveat on that figure: if your server already applies gzip or brotli, the additional win from minification is much smaller, because those algorithms compress repeated whitespace very efficiently. Minify anyway for data you store in bulk or embed in another document, but do not expect dramatic gains on an already-compressed HTTP response.

Two spaces is the most common indentation and what most formatters default to. Four is also widely used. Tabs are valid but unusual.

Reading an unfamiliar payload

When an API returns something you did not expect, formatting it is the first step — but a few habits help beyond that.

Check the types, not just the values. An ID arriving as "123" rather than 123 will break a strict comparison, and the difference is easy to miss when scanning.

Watch for null versus missing. A key present with a null value and a key absent entirely are different states, and APIs are frequently inconsistent about which they use. Your code probably handles one and not the other.

Look at array emptiness. An empty array and a null are both common representations of "nothing here", and again, inconsistently applied.

Our JSON formatter runs entirely in your browser, which matters here — API responses routinely contain tokens, personal data and internal identifiers you should not paste into a server-side tool.

Error messages and what they mean

• "Unexpected token } in JSON at position N" — almost always a trailing comma just before that brace.
• "Unexpected token ' " — single quotes.
• "Unexpected end of JSON input" — the document is truncated. Usually a response that was cut off, or a file that did not finish writing.
• "Unexpected token < in JSON at position 0" — you are parsing HTML, not JSON. The server returned an error page and your code tried to parse it. Check the status code before parsing.

That last one is worth internalising; it is one of the most frequently searched error messages in web development, and the cause is never a JSON problem.

Frequently asked questions