Common JSON Parsing Errors and How to Fix Them

Why JSON.parse throws instead of guessing

JavaScript object literals are forgiving: unquoted keys, trailing commas, single-quoted strings, and comments are all legal, because the engine parses that source like any other code. JSON is a much smaller, stricter grammar (RFC 8259), and JSON.parse() enforces every rule of it with no fallback. The parser reads left to right and stops at the first token that doesn't fit the grammar at that position.

The designers chose that on purpose. A lenient JSON parser would accept slightly different documents in different implementations, the exact interoperability problem JSON set out to avoid. The cost: error messages are terse and positional. The parser tells you where the grammar broke, not what you meant to write.

Trailing commas

The most common JSON error is a trailing comma left over from editing a JavaScript object literal (where it's legal).

{
  "name": "Alice",
  "roles": ["admin", "editor"],
}

V8 rejects this at the closing brace, not at the comma, because the comma stays valid grammar until the parser expects another property and finds `}` instead. Depending on your Node/Chrome version you'll see something like `Unexpected token '}', "...editor"],\n}"... is not valid JSON` (newer V8, with a snippet) or the older, terser `Unexpected token } in JSON at position 47`. Either way, delete the comma before the closing bracket or brace.

Single quotes and unquoted keys

JSON requires double quotes for every string and every key. Single-quoted strings and bare (unquoted) keys show up all the time when people hand-type JSON or copy-paste it from JavaScript source.

{ 'name': 'Alice' }
{ name: "Alice" }

A leading single quote produces something like `Unexpected token ''', "{ 'name'"... is not valid JSON`. An unquoted key reports differently: modern V8 recognizes that it expected a property name and reports `Expected property name or '}' in JSON at position 2` without naming the bare identifier. The fix is mechanical either way: wrap every key and every string value in double quotes.

Unescaped newlines and control characters inside strings

JSON forbids a raw newline, tab, or other control character (anything below U+0020) inside a string. Escape it as `\n`, `\t`, and so on. This bites most often when code builds JSON by concatenating a multi-line value (a log message, a code snippet, a user comment) into a string literal without escaping it.

{
  "message": "line one
line two"
}

This produces `SyntaxError: Bad control character in string literal in JSON at position 21`, one of the few JSON errors that names the problem instead of a token. Escape the character instead of letting it appear raw: `"line one\nline two"`.

Duplicate keys, NaN/Infinity/undefined, and BOM characters

Three quieter failure modes deserve a name. First, duplicate keys in a JSON object don't cause a parse error. `{ "id": 1, "id": 2 }` parses, and JSON.parse keeps the last occurrence (`id: 2`) and discards the first without warning. RFC 8259 says names 'should' be unique but doesn't require parsers to reject duplicates, so your parser is spec-compliant here, and reviewers miss the bug easily.

Second, `NaN`, `Infinity`, and `undefined` are valid JavaScript but invalid JSON tokens. JSON has `number` without the IEEE-754 special values, and no `undefined` (only `null`). `{ "value": NaN }` throws `Unexpected token 'N', ..."value":NaN}"... is not valid JSON` (or `Unexpected token N in JSON at position 10` on older engines). `JSON.stringify` converts `NaN`/`Infinity` to `null` and drops `undefined` values, so this error usually means someone hand-wrote the JSON or a non-JS source assumed JS semantics.

Third, a UTF-8 byte-order-mark (U+FEFF) at the start of a file breaks `JSON.parse` when you read the file as a raw string, producing `Unexpected token '\ufeff'... is not valid JSON` at position 0. Windows editors and some Java/.NET tools add it when saving UTF-8. The problem is specific to `JSON.parse` on a string: `Response.json()` in the Fetch API decodes UTF-8 text and strips a leading BOM during that decode, so the same bytes can behave differently over HTTP and when read from disk with `fs.readFileSync(path, 'utf8')`.

Reading the position, and when to reach for a repair tool

The `position` in a JSON.parse error is a zero-indexed character offset into the exact string you passed in, not a line number. Node (v20+) also appends a `(line X column Y)`, but older runtimes and browsers give only the raw offset. Two things trip people up. The position marks where the parser noticed the broken grammar, which for a trailing comma or a missing bracket often sits one token after your mistake. And if you pretty-printed the JSON for readability while debugging the original minified string, the offsets won't match what's on your screen.

For a one-off syntax slip in a short document, fix it by hand once you've located the position. Paste it into a validator that highlights the exact character instead of counting offsets. For a large file with several unrelated errors, JSON from a buggy upstream tool, or JSON mangled by rounds of copy-paste, hand-fixing costs too much time. Reach for automation then. JsonForge's JSON Validator pinpoints every schema violation with a precise path once the document parses, and JSON Repair fixes common structural mistakes (missing quotes, trailing commas, mismatched brackets) when the input is too mangled to fix one error at a time.