The 10 JSON Syntax Errors You'll Actually Hit (and How to Fix Each One)
JSON's grammar fits on a single page, which is exactly why its errors are so frustrating: the format is strict, and parsers rarely tell you why something is wrong — only where they gave up. "Unexpected token } in JSON at position 214" is technically accurate and practically useless.
This guide walks through the errors that account for nearly every broken JSON document we've seen in practice, what causes each one, and how to fix it. Every example is valid or invalid according to RFC 8259, the current JSON standard.
1. Trailing commas
The single most common error. JavaScript, Python, Go, and most modern languages allow a comma after the last item in a list. JSON does not.
{
"name": "api-gateway",
"port": 8080, <-- invalid: nothing follows this comma
}Fix: remove the final comma. If you're generating JSON by string concatenation in a loop, that's the root cause — build a native object or array and serialize it with JSON.stringify, json.dumps, or your language's equivalent instead.
2. Single-quoted strings
JSON strings must use double quotes. Single quotes are a JavaScript and Python habit that leaks in when someone copies an object literal or a Python dict repr.
{'status': 'ok'} invalid
{"status": "ok"} validA tell-tale sign of a Python repr pasted in as JSON is the presence of True, False, or None. JSON's literals are lowercase true, false, and null.
3. Unquoted keys
Object keys must be strings, and strings must be quoted. {status: "ok"} is a valid JavaScript object literal but invalid JSON. This usually happens when someone hand-writes a payload for a test or copies it out of browser DevTools' object preview rather than the raw response.
4. Comments
JSON has no comment syntax — neither // nor /* */. Douglas Crockford removed them deliberately so that nobody could use comments to carry parsing directives.
That's awkward for configuration files, which is why several tools accept extended formats: tsconfig.json and VS Code's settings are actually JSONC (JSON with comments), and JSON5 additionally allows trailing commas, single quotes, and unquoted keys. If a file parses in your editor but fails in JSON.parse, check whether the tool that owns it is using one of these supersets.
Fix: strip the comments, or if you control the format, move the explanation into a dedicated field such as "_comment" or switch the file to YAML or TOML, which both support comments natively.
5. Unescaped control characters and quotes inside strings
A raw newline or tab inside a JSON string is invalid. So is an unescaped double quote. These must be written as escape sequences:
| Character | Escape |
|---|---|
| Double quote | \" |
| Backslash | \\ |
| Newline | \n |
| Carriage return | \r |
| Tab | \t |
| Any code point | \uXXXX |
Windows file paths are a frequent casualty: "C:\temp\new" written with single backslashes contains \t and \n, which a parser happily reads as a tab and a newline — or rejects outright for sequences like \q that aren't valid escapes at all. Double every backslash, or use forward slashes, which Windows accepts in most APIs.
6. NaN, Infinity, and undefined
JSON numbers are finite decimals only. NaN, Infinity, and -Infinity are not valid, and neither is JavaScript's undefined.
The trap here is that some serializers produce them anyway. Python's json.dumps(float("nan")) outputs NaN by default; pass allow_nan=False to make it raise instead. JavaScript's JSON.stringify takes the opposite approach and silently converts NaN to null and drops object properties whose value is undefined — so the output is valid, but your data changed without warning.
7. Leading zeros, leading plus signs, and hex
These are all invalid JSON numbers: 007, +1, .5, 5., and 0xFF. Write 7, 1, 0.5, 5.0 (or 5), and 255.
If a value like a ZIP code, phone number, or account ID genuinely needs its leading zeros, it isn't a number — store it as a string.
8. A byte-order mark at the start of the file
Some Windows editors save UTF-8 files with an invisible byte-order mark (BOM, EF BB BF) at the very start. RFC 8259 says implementations must not add one and may ignore one, which in practice means some parsers accept it and others fail with a confusing "unexpected token" at position 0 — on a file that looks perfectly fine.
Fix: re-save the file as "UTF-8" rather than "UTF-8 with BOM", or strip the first character when it is \uFEFF before parsing.
9. Multiple top-level values
A JSON document contains exactly one value. Two objects back to back — {"a":1}{"b":2} — is not valid JSON. This usually means you're looking at JSON Lines (also called NDJSON), a log-friendly format where each line is its own JSON document. Parse it line by line, or wrap the objects in an array if you need one document.
10. Duplicate keys
This one is sneaky because it usually doesn't error. RFC 8259 says keys "SHOULD be unique" but doesn't require it, so most parsers accept duplicates and keep the last value. {"role":"user","role":"admin"} parses to role: "admin" in JavaScript and Python alike.
That silent behavior has caused real security bugs when two components in a pipeline disagree about which duplicate wins. If you accept JSON from untrusted sources, use a parser mode that rejects duplicates — Python's object_pairs_hook can do this in a few lines.
A quick debugging workflow
- Get the exact position. Most parsers report a character offset or a line and column. Jump straight there rather than scanning by eye.
- Look just before the reported spot. The parser reports where it gave up, which is often one token after the real mistake — a missing comma on line 12 surfaces as an error at the start of line 13.
- Pretty-print what does parse. For a large minified payload, formatting the document with indentation turns "position 48,211" into a specific line you can read.
- Check the source, not just the text. If the same generator keeps producing bad JSON, fix the generator. Hand-repairing the output is a treadmill.
Preventing these errors in the first place
- Never build JSON by string concatenation. Serialize native data structures.
- Validate JSON at system boundaries — on the way in from users, and before writing config files — so failures happen close to their cause.
- Use an editor with live JSON validation so syntax errors are flagged as you type, not at deploy time.
- For structural rules beyond syntax (required fields, types, allowed values), add a JSON Schema — see our practical introduction to JSON Schema.