JSON has exactly six data types and one rigid grammar — which means it fails in a small, learnable set of ways. These are the twelve that account for nearly every Unexpected token you’ll ever see, ordered roughly by how often they bite. Paste any of the broken samples into the formatter to see the error position it reports.

1. Trailing comma

{ "name": "ada", "age": 36, }

The comma after 36 tells the parser another "key": value pair is coming — then } arrives instead. Same in arrays: [1, 2, 3,]. Fix: delete the last comma. JavaScript, Python and Go tolerate this; JSON doesn’t.

2. Single quotes

{ 'name': 'ada' }

JSON strings are double-quoted, always — the spec defines one string delimiter. 'ada' fails at the very first '. Fix: convert every ' to " (careful with apostrophes inside the text itself: "it's" is fine as-is).

3. Unquoted keys

{ name: "ada" }

JavaScript object literals allow bare identifiers as keys; JSON requires every key to be a double-quoted string. Fix: {"name": "ada"}. This is the signature of a hand-edited JS config pasted into a .json file.

4. Comments

{
  // TODO: rotate this key
  "api_key": "..."
}

Neither // nor /* */ exists in JSON. Fix: remove the comment, or move the note into a real key ("_comment": "rotate this" is a common convention). If your tool needs comments, it’s probably reading JSONC or JSON5 — check which format the file actually is.

5. Python literals leaking in

{ "active": True, "org": None, "ratio": float("nan") }

Pasted from a Python dict print or a REPL. JSON spells them true, false, null — lowercase — and has no NaN. JavaScript’s undefined fails the same way. Fix: map True→true, False→false, None→null, NaN→null (or a string like "NaN").

6. Unescaped control characters

{ "bio": "line one
line two" }

A literal newline inside a string is illegal — control characters below U+0020 (newline, tab, carriage return) must be escaped. Fix: "line one\nline two", \t for tabs. The usual culprit is a pasted log message or a certificate PEM block with real line breaks.

7. Trailing garbage — two values in one text

{} {}

A JSON text is one complete value — object, array, string, number or literal. Anything after the closing token is an error (“Unexpected non-whitespace character”). Fix: if it’s a log or export file, it’s probably JSON Lines (one JSON value per line) — split on newlines and parse each line, don’t parse the file.

8. Unterminated string

{ "name": "ada }

Missing the closing " means the parser reads to end-of-file still “inside” the string, so the error is usually reported at the last character — nowhere near the real problem. Fix: find the opening quote (our error report points at it, not at EOF) and add its partner. A stray literal " inside the string creates the mirror-image bug: escape it as \".

9. Numbers that aren’t JSON numbers

{ "price": 01, "hex": 0xFF, "big": 1,024, "frac": .5 }

Four violations in one object: no leading zeros (01), no hex/octal (0xFF), no thousands separators (1,024 parses as 1 then errors at the comma), and a digit must precede the decimal point (.5 → 0.5). Legal: -0.5, 6.022e23, 1E-9. Illegal: +5, Infinity, 0b101.

10. The invisible BOM

Files saved by Windows editors sometimes start with U+FEFF, a zero-width byte-order mark. It looks like a perfectly good { at position 0 and parses as “unexpected character.” Fix: delete the first invisible character (our validator flags it specifically), or re-save the file as “UTF-8 without BOM.”

11. Missing comma between elements

[ "a", "b" "c" ]

The opposite of #1: a comma is required between elements. The error surfaces at "c" — where the parser expected , or ] — not where you forgot to type. Same story for {"a": 1 "b": 2}.

12. Truncated paste

{ "users": [ {"id": 1, "name": "a

Copying a huge response and losing the tail is the most frustrating error because the document is almost valid: the parser hits end-of-input inside an open structure. Fix: there is no repair — re-copy the whole payload. The error will point at the end of input and name what’s missing (an unclosed array, an open string).

The messages parsers actually print

Parser	Typical message	Position info
Chrome/Node (V8)	Expected ',' or '}' after property value in JSON at position 41	character offset
Firefox (SpiderMonkey)	JSON.parse: expected ',' or '}' after object property at line 3 column 14	line + column
Safari (JavaScriptCore)	JSON Parse error: Expected '}'	none
Python json	Expecting ',' delimiter: line 3 column 14 (char 41)	line, column, offset
Go	invalid character 'x' looking for beginning of object key string	byte offset

This tool reports line and column for every error — computed by its own grammar walk — so the message is consistent no matter which browser you open it in.

Errors that aren’t syntax errors

Two traps worth knowing because they pass a validator and still break things:

• Duplicate keys — {"a": 1, "a": 2} is legal; most parsers silently keep the 2. Security-sensitive code has been fooled by pairs like {"role": "user", "role": "admin"} where two different parsers chose different winners.
• Numbers beyond IEEE-754 — 9007199254740993 parses fine, then reads back as 9007199254740992. If your IDs are 64-bit integers, keep them as strings.

Frequently asked questions

What's the single most common JSON syntax error?

The trailing comma — a comma after the last element of an object or array, like [1, 2,]. It's legal in JavaScript, Python and most modern config formats, so muscle memory types it constantly. JSON forbids it outright: a comma is a separator, not a terminator, so the parser expects another value after it.

Why does the error position point at a spot that looks fine?

Parsers report where they noticed the problem, which is often one token after the real mistake. An unterminated string is noticed at end-of-input; a missing comma is noticed at the start of the next token. When the flagged position looks innocent, look one token backwards — or at the end of the previous line.

My JSON is valid but the API still rejects it — why?

Syntax-valid isn't schema-valid. A document can parse perfectly yet fail because a field is missing, a number arrived as a string, or a value isn't in an expected enum. That's a different layer of checking — see what JSON Schema is for how APIs describe and enforce shape.

Can a JSON file contain comments?

Standard JSON cannot — Douglas Crockford deliberately left comments out to keep parsers trivial and prevent parsing directives from sneaking in. If you need comments in a config file, the format you're looking for is JSON5 or JSONC, both of which are supersets that allow them.