Trailing commas
Strict JSON does not allow a comma after the final element of an array or object. JavaScript does. Python does not. Go does. Ruby does not. This is the single most common cause of "unexpected token" errors when a JS developer pastes a JS object literal into a JSON parser.
Fix: remove every comma before ] and }. If you are producing JSON from JavaScript, remember that JSON.stringify handles this correctly; it is only hand-edited files that break.
Single-quoted strings
JSON requires double-quoted strings. Keys must be double-quoted, values must be double-quoted (if they are strings). Object literals from JavaScript often use single quotes and they are invalid JSON even if they are perfectly valid JavaScript.
Fix: replace every single quote wrapping a key or string value with a double quote. Do not bulk replace — some strings contain apostrophes you do not want to damage.
Unquoted keys
{name: "Ada"} is valid JavaScript; it is not valid JSON. Every key must be a double-quoted string.
Leading BOM characters
If a file was saved in Notepad (or any UTF-8-with-BOM Windows editor), the first byte is an invisible 0xEF 0xBB 0xBF sequence. JSON parsers reject it as "unexpected character". Re-save the file as UTF-8 without BOM.
NaN, Infinity, undefined
None of these are valid JSON. JavaScript lets you stringify them — but the result is invalid JSON that no other language will parse. If you need to represent missing values, use null. If you need to represent infinity, pick a sentinel value like 9999 or the string "inf" and document it.
Comments — not allowed
// line comments and /* block */ comments are JavaScript, not JSON. If you need comments, use JSON5 (a superset) or YAML. Many tool configs are JSON-with-comments; strip them before parsing with a JSON.parse.
Duplicate keys
Strict JSON does not define the behaviour of duplicate keys. Most parsers accept them and keep the last occurrence, but RFC 8259 explicitly says this is implementation-defined. Do not rely on the order; de-duplicate first.