"Unexpected token in JSON" — What It Means and How to Fix It

Every variant of the error carries up to three clues: the token (the exact character the parser rejected), the position (a zero-based index into the string you passed to JSON.parse), and, in newer engines, a line and column. The wording depends on the JavaScript engine, not on your code. Modern V8 — Chrome, Edge, Node 20+ — quotes the token with a context snippet, which is what the validator above shows for the preloaded sample. Older V8 said "Unexpected token a in JSON at position 24". Firefox reports "at line 1 column 25 of the JSON data", and Safari names the identifier it stumbled over. Same failure, four spellings — never string-match on error text.

Two things trip people up. First, the position is where the parser gave up, not always where the bug lives: a quote that was never closed turns everything after it into one long string, so the failure gets reported far downstream of the real mistake. When the position looks nonsensical, scan backwards for an unbalanced quote. Second, the position indexes the exact string your code received — including every space and newline — not a pretty-printed copy of it.

Parsers also stop at the first illegal character, so a document with several mistakes reports exactly one error. The sample on this page demonstrates it: fix the unquoted admin and a second error appears at the missing comma. Fix, re-validate, repeat — the loop takes seconds in the validator above.

"Unexpected token < in JSON at position 0" is the most-searched variant for a reason: the body starts with <, which means HTML. The usual producers are a 500 or 502 error page from a proxy, a login page served after an expired session (the API redirected instead of returning a 401 with a JSON body), and an SPA rewrite answering a mistyped API path with index.html. The empty-body twin is "Unexpected end of JSON input" thrown on the very first parse: a 204 No Content, an empty reply from a crashed handler, or res.json() called on a response that never had a body.

The debugging recipe is one line: read the body as text before you parse it. const text = await res.text(); console.log(res.status, res.headers.get("content-type"), text.slice(0, 200)) shows instantly whether JSON ever arrived — then call JSON.parse(text) yourself. Note that res.json() and res.text() both consume the body stream, so you cannot log the text after res.json() has already failed. That is exactly why the blind res.json() call makes this error so opaque.

Once you can see the real payload, the fix lives in the request or the server, not in the JSON: correct the URL or base path, send the missing auth header, make the API return JSON error bodies with proper status codes, or point the dev proxy at the right port.

When the position lands inside the document, the cause is nearly always one of five patterns. Single quotes: {'name': 'Ada'} is valid JavaScript, invalid JSON. Unquoted keys: {name: "Ada"} — same story. Unquoted values: "role": admin, the first bug in the sample above. Missing commas: ["read" "write"], the second bug — modern V8 even spells out the repair, "Expected ',' or ']' after array element". Trailing commas: [1, 2, 3,] before a closing bracket.

A second family comes from serializing by hand. NaN, Infinity, and undefined leak out of JavaScript string concatenation; True, False, and None leak out of Python when someone ships str(dict) instead of json.dumps. Smart quotes arrive via copy-paste from Word, Google Docs, or Slack and look identical to straight quotes until a parser rejects them. One rule prevents the entire class: never build JSON by concatenating strings — always emit it with JSON.stringify or json.dumps.

Part of this class is automatable. JSON Repair deterministically converts single and smart quotes, quotes bare keys, strips trailing commas and comments, translates Python and JavaScript literals, and removes markdown fences — reporting each fix it applied. What it will not do is guess: a bare value like admin (should it be "admin", or did a variable fail to interpolate?) and a missing comma between two closed strings are ambiguous, so repair re-throws the parse error instead of inventing data. For those two, the validator points at the character and the fix is one keystroke.

This message means the parser ran out of characters while something was still open — a string missing its closing quote at the very end, an array missing its ], an object missing its }. The usual producers: log pipelines that cap line length, proxies and gateways with response-size limits, curl output interrupted by a timeout, a copy-paste that missed the tail, a streamed fetch body parsed before the stream finished, and LLM responses that hit their token limit mid-object.

Truncation is the one case worth automating. JSON Repair closes unfinished strings and brackets deterministically — no AI involved, same output every time — and tells you what it did: feed it {"user": "Ada", "scopes": ["read", "wri and it returns valid JSON with the status "Repaired — closed unclosed brackets". The caveat is honest: repair restores syntax, not data. Whatever was cut off is gone, so treat the repaired document as a way to inspect what survived, and re-fetch or re-export the source when you need the complete payload.

To stop it recurring: compare Content-Length against the bytes you actually received, await the complete body before parsing, raise the size limit on whichever proxy clipped the response, and for LLM output either raise max tokens or request smaller chunks. Once the JSON parses, the Open in full editor button carries it into the editor for tree view, formatting, mind maps, and AI-assisted cleanup.