Common JSON errors and how to fix them
The mistakes that break parsers — and the standard-compliant fixes.
Most “invalid JSON” failures come from writing JavaScript object literals (or almost-JSON configs) and expecting every tool to accept them. JSON is stricter than JS. This guide lists the errors people hit constantly, why they fail under RFC 8259, and how to repair them. Use JSON Quiet to Validate after each fix; pair this page with the validation guide if you need mode details.
Trailing commas
Broken: {"a": 1, "b": 2,} or [1, 2, 3,]
JavaScript often allows a comma after the last element. Standard JSON does not. Remove the final comma so the last property or array item stands alone: {"a": 1, "b": 2} and [1, 2, 3].
Tip: when editing by hand, add a new property before the previous last item, or delete the trailing comma explicitly before saving. If you are cleaning a large paste, JSON Quiet’s relaxed mode may help you iterate, but switch to strict RFC 8259 before you ship.
Single quotes instead of double quotes
Broken: {'name': 'Ada'}
JSON strings and object keys must use double quotes. Single quotes are a JavaScript convenience, not JSON. Fix: {"name": "Ada"}. Watch for apostrophes inside strings — in JSON they do not need escaping the way double quotes do: {"note": "Ada's book"} is fine.
Unquoted keys
Broken: {name: "Ada", age: 36}
Object member names must be quoted strings in JSON. Fix: {"name": "Ada", "age": 36}. This mistake is extremely common when copying from JS, TypeScript, or casual pseudocode.
Comments
Broken: anything with // comment or /* block */ inside the document.
JSON has no comment syntax. Config formats that look like JSON but allow comments (JSONC, JSON5, some editor settings files) are not portable JSON. For true JSON, remove comments or move explanations outside the file (README, schema descriptions). If you need comments in a project format, use a documented superset and a parser that supports it — do not expect RFC 8259 validators to accept them.
NaN, Infinity, and undefined
Broken: {"score": NaN}, {"x": Infinity}, {"y": undefined}
These are JavaScript values, not JSON tokens. JSON numbers are finite decimal literals; the only literal names are true, false, and null. Fixes depend on meaning: use null for missing values, omit the property if “undefined” means absent, or encode non-finite numbers as strings (for example "NaN") only if both sides agree on that convention.
Unescaped characters in strings
Strings cannot contain raw control characters or an unescaped double quote. A quote inside a string must be written as \". Backslashes must be escaped as \\. Newlines inside a string should use \n rather than a literal line break (unless you are using a format that explicitly allows something else — standard JSON does not).
If Validate fails “in the middle of a string,” look for an earlier unescaped " that closed the string too early.
Wrong root or concatenated values
Broken: two objects back-to-back {}{}, or bare words that are not a single JSON value.
A JSON text is one value: an object, array, string, number, or literal. NDJSON (one JSON value per line) is a different convention — validate each line separately, not the whole file as one document, unless your tool supports NDJSON explicitly.
Duplicate keys
RFC 8259 does not require parsers to reject duplicate object keys, but behavior is unpredictable: some keep the first, some the last. Prefer unique keys. If you see surprising data after a parse, search for repeated property names.
Numbers with leading zeros or bad formats
Values like 01 or 3. can be rejected depending on strictness. Use canonical forms: 1, 3.0, scientific notation where appropriate (1e3). Do not put quotes around numbers unless you truly want a string.
A repair workflow that works
- Paste the text into JSON Quiet.
- Click Validate with RFC 8259 selected.
- Jump to the reported line/column; match the symptom to a section above.
- Apply the smallest fix; validate again.
- When valid, Format for readability and copy the result. See how to format JSON.