Common JSON Validation Errors and How to Fix Them
The ten most common JSON syntax errors developers encounter — trailing commas, single quotes, unquoted keys, comments — with examples and fixes for each.
JSON has arguably the strictest syntax of any common data format. One misplaced character breaks the entire document. Unlike JavaScript (which allows trailing commas and comments) or YAML (which is forgiving with quoting), JSON has no error recovery — if it's wrong, it's wrong.
Understanding why JSON is this strict, and knowing what each error looks like, is what separates developers who spend 30 seconds fixing a JSON bug from those who spend 30 minutes.
Why JSON Is So Strict
JSON was designed by Douglas Crockford as a safe, minimal subset of JavaScript. The strict grammar was intentional: parsing should be fast, unambiguous, and deterministic. Any parser anywhere in the world should produce the same result from the same input.
This is what makes JSON suitable as a universal interchange format. The strictness is a feature. But it does mean the spec has zero tolerance for syntax errors.
The Ten Most Common JSON Validation Errors
1. Trailing comma
The single most common JSON error. JSON does not allow a comma after the last element in an object or array.
Broken:
{"name": "Alice", "age": 30,}
Fixed:
{"name": "Alice", "age": 30}
This is so common because nearly every programming language (JavaScript with ES5+, Python, Ruby, Rust, Go, Swift) allows trailing commas in their own syntax. Developers write them habitually and forget JSON doesn't.
2. Single quotes instead of double quotes
JSON requires double quotes for all strings — keys and values alike. Single quotes are not valid.
Broken:
{'name': 'Alice', 'role': 'admin'}
Fixed:
{"name": "Alice", "role": "admin"}
This comes up constantly when copying from Python (which uses single quotes by convention) or from JavaScript template literals.
3. Unquoted keys
JSON keys must be strings — and strings must be quoted. JavaScript object literal syntax allows unquoted keys; JSON does not.
Broken:
{name: "Alice", age: 30}
Fixed:
{"name": "Alice", "age": 30}
4. Comments
JSON does not support comments. Not // single-line comments, not /* */ block comments. Nothing.
Broken:
{
// user settings
"theme": "dark",
"language": "en" /* default */
}
Fixed (remove comments entirely):
{
"theme": "dark",
"language": "en"
}
If you need comments in config files, use YAML (which supports # comments) or JSON5 / JSONC (which are extensions that add comment support, supported by VS Code and some tools).
5. undefined, NaN, Infinity
JSON only supports: strings, numbers, booleans (true/false), null, arrays, and objects. JavaScript-specific values are not valid.
Broken:
{"score": NaN, "threshold": Infinity, "value": undefined}
Fixed — replace with null or remove the field:
{"score": null, "threshold": null}
6. Missing comma between items
Every item in an array or object must be separated by a comma.
Broken:
{"a": 1 "b": 2}
Fixed:
{"a": 1, "b": 2}
7. Numbers with leading zeros
JSON does not allow numbers like 007 or 0123. Only 0 itself is a valid zero-prefixed number.
Broken:
{"zip_code": 01234}
Fixed — use a string if the leading zero is meaningful:
{"zip_code": "01234"}
8. Hex and octal literals
JSON only supports decimal numbers. 0xFF and 0o77 are not valid JSON.
Fixed:
{"value": 255}
9. Python/Ruby boolean and null values
Python uses True, False, None. Ruby uses true, false, nil. JSON requires lowercase true, false, null.
Broken (Python):
{"active": True, "score": None}
Fixed:
{"active": true, "score": null}
This is why DevConvert has a Python Dict parser — it normalises these values automatically.
10. Escaped characters in strings
JSON strings can only contain a specific set of escape sequences: \n, \t, \r, \\, \", \/, \uXXXX. Other escape sequences (like \a, \b used in other contexts) may not be valid.
Broken (raw backslash):
{"path": "C:UsersAlice"}
Fixed:
{"path": "C:\\Users\\Alice"}
A Quick Mental Model
When debugging JSON, check in this order:
1. Are all keys double-quoted?
2. Are there trailing commas?
3. Are there comments?
4. Are there non-JSON values (undefined, NaN, True, None)?
5. Are all strings properly closed?
Most errors fall into one of those five categories.
What a Good JSON Validator Shows You
A good validator doesn't just say "invalid" — it tells you the line and column of the error, what token was unexpected, and ideally what the parser expected instead. This is what makes the difference between fixing a bug in 10 seconds vs hunting for 10 minutes.