1. Trailing commas
Broken: {"a": 1, "b": 2,}
Fixed: {"a": 1, "b": 2}
JavaScript allows a comma after the last item; JSON does not. Linters and formatters often insert trailing commas automatically, so this error appears most when copying JS object literals into JSON. Our JSON formatter flags it as "Trailing comma is not allowed in JSON" with the exact line and column.
2. Single quotes
Broken: {'name': 'Ada'}
Fixed: {"name": "Ada"}
JSON mandates double quotes for every string and key. If your data contains apostrophes ("don't"), double-quoted JSON handles them without escaping — one of the format's quiet conveniences.
3. Unquoted or partially quoted keys
Broken: {name: "Ada"}
Fixed: {"name": "Ada"}
Again valid in JavaScript, invalid in JSON. Every object key must be a double-quoted string, no exceptions — even keys that look like identifiers.
4. Comments
Broken: {"a": 1 /* count */}
Fixed: remove the comment, or move it to external documentation.
JSON has no comment syntax — a deliberate choice to keep parsers simple and payloads unambiguous. Config files that need comments usually use JSON5, YAML, or TOML instead.
5. Unescaped control characters
Broken: a literal line break inside a string value.
Fixed: escape it as
(similarly , ", \).
Strings cannot contain raw newlines, tabs, or other control characters. When generating JSON by hand-concatenating strings (do not do this — use a serializer), these are the bugs that slip through.
6. Bad numbers
Broken: {"n": 01}, {"n": NaN}, {"n": .5}
Fixed: {"n": 1}, {"n": null}, {"n": 0.5}
JSON numbers cannot have leading zeros, cannot be NaN or Infinity, and need a digit before the decimal point. APIs that need to express "not a number" typically use null or a string.
7. Mismatched brackets and missing colons
Broken: {"a" 1} or {"a": [1, 2}
Fixed: {"a": 1} and {"a": [1, 2]}
In large payloads these are hard to eyeball. Strategy: format the document to reveal the structure, then check the reported error location — it is usually within a line or two of the actual mistake, often pointing at the token after the missing one.
Preventing JSON errors before they happen
Fixing errors is good; not writing them is better. Three layers of prevention:
- Editor support. VS Code and most editors validate JSON as you type — red squiggles, hover explanations, and auto-closing brackets catch the majority of mistakes at the source. Enable "JSON: format on save" and trailing-comma errors largely disappear.
- Never hand-build JSON in code. String-concatenating
"{\"name\": \"" + name + "\"}"is where escaping bugs breed. Every language has a serializer (JSON.stringify,json.dumps,json.Marshal) — use it and let the library handle quotes, escapes, and unicode. - Validate at the boundary. APIs should reject malformed payloads with clear 400 errors; CI pipelines should lint config files before deploy. A JSON Schema adds the next level: not just "is it valid JSON" but "does it have the fields and types we expect."
When errors do slip through — a vendor's webhook payload, a hand-edited config at 2 AM — keep the JSON formatter bookmarked. Paste, read the line and column, fix, re-validate: the whole loop takes under a minute once it becomes reflex, and it beats staring at raw payloads every single time.
The fastest debugging loop: paste into the JSON formatter, read the line/column, fix, re-validate. For the fundamentals, see JSON for beginners; for shipping payloads, read minify vs. format.