Why Your JSON Is Invalid — Every Error Explained

Every JSON parse error carries a character offset — Unexpected token } in JSON at position 412 — and that offset is the single most useful piece of information you have. It is exact. The token named in the message is often not the mistake; it is the first place the parser could no longer make sense of the document, which is frequently just after the real problem.

That distinction explains the most confusing category of error. A missing comma is reported at the next token, not at the gap. An unterminated string is reported wherever the parser eventually gave up, which can be hundreds of characters later.

Practically: paste the document into the formatter, which converts the position into a line number and highlights it, and look at the token before the one named. Browsers differ in wording — Chrome, Edge and Node use V8's phrasing, Firefox says things like SyntaxError: JSON.parse: unexpected character at line 1 column 5, Safari has its own — but all of them tell you where.

If the whole document is one line, the line number will say 1 and only the offset is useful. Format it first, then re-parse, and the error moves to a line you can see.

The most common JSON error there is.

{
  "name": "Ada",
  "born": 1815,
}

That comma after 1815 is legal in JavaScript, in Python, and in most people's muscle memory. It is a hard syntax error in JSON, in both objects and arrays, and MDN's JSON.parse documentation demonstrates exactly this failure. The parser reads the comma, expects another member, finds } and reports the brace — which is why the message points at a character that looks perfectly innocent.

Fix: remove the comma. If your editor added it, that is a formatter configured for JavaScript rather than JSON. The repair function in the formatter removes trailing commas throughout a document in one pass.

The same message with ] is the array version of the identical mistake.

JSON has no single-quoted strings, for keys or values, anywhere.

{ 'name': 'Ada' }

Both quotes are wrong here, and so is the unquoted variant { name: "Ada" }. This error almost always means the text started life as a JavaScript or Python literal and was pasted in as if it were JSON. Python is the worst offender: str() on a dict produces single quotes, capitalised True/False and None, none of which are JSON. Python's own json.dumps produces correct JSON — the mistake is using the wrong function.

Fix: double quotes throughout. The formatter's repair converts single-quoted strings to double-quoted ones with a state machine rather than a find-and-replace, so an apostrophe inside an already-valid string — "it's fine" — survives instead of being turned into a broken quote.

{ name: "Ada", born: 1815 }

Valid JavaScript, invalid JSON. Every key must be a double-quoted string.

This is the signature of a payload copied out of source code, a browser console, or a log line that printed an object rather than serialising it. It is also what you get from a hand-written config file where the author reasonably assumed the quotes were optional.

Fix: quote every key. The repair handles this too, and it is careful about where it applies: quoting bare keys with a naive regex on the whole document rewrites the inside of strings as well, turning {"url": "http://example.com"} into nonsense because of the colon after http. The tool's repair only rewrites structure outside string literals for exactly that reason.

The parser reached the end of the text still waiting for something: a closing brace, a closing bracket, or the rest of a string.

Three causes, in order of how often they happen:

The response was empty. Parsing an empty string produces exactly this error, and an empty string is what you get from a 204 response, a failed request whose body you never checked, or a fetch that resolved before the body arrived. This is the most common cause by a wide margin, and the fix is upstream: check the status and whether the body is non-empty before parsing.

A brace or bracket is unclosed. Count them, or let the formatter do it. Deeply nested documents assembled by hand are where this lives.

The transfer was cut off. A file copy interrupted mid-write, a stream that closed early, a log rotated between the write and the read. If the document ends mid-value, this is why.

Fix: if the text is empty, fix the caller rather than the JSON. Otherwise, close what is open — the position of the last successfully parsed token tells you which container you are still inside.

A literal line break inside a quoted string is invalid, and so is a literal tab. They must be written as the escapes \n and \t.

This is the error that catches multi-line content: a PEM certificate, a SQL query, an address block, a log message with a stack trace in it. All of them contain real newlines, and all of them have to be escaped before they can sit inside a JSON string.

Firefox words it differently — bad control character in string literal — but it is the same problem.

Fix: escape the string before embedding it. The escape tool does this mechanically, and escaping strings in JSON covers the nesting case, where a value that is itself JSON needs its quotes and backslashes escaped a second time.

The related failure is an unterminated string, which is what you get when a quote inside a string was not escaped: {"quote": "she said "hi""}. The parser closes the string at the second quote and then finds a bare word where it wanted a comma.

NaN, Infinity, -Infinity and undefined are not JSON values. Neither are True, False and None — JSON's literals are lowercase true, false and null.

Where these come from:

• A serialiser that was not a JSON serialiser. Something printed a language-native representation instead of encoding it.
• A division by zero upstream. JavaScript's JSON.stringify converts NaN and Infinity to null rather than erroring, so if you are seeing the literal text NaN, the document was not produced by JSON.stringify.
• Python. json.dumps will happily emit NaN and Infinity by default, which is valid to Python's own parser and invalid to almost everyone else's. Pass allow_nan=False and it raises instead of producing something no one else can read.

Fix: decide what those values should mean in your data — null, a string, or an omitted key — and fix the producer. There is no way to represent them in JSON, so this one cannot be patched at the parsing end.

When the error points at position 0 or 1 and the first character is visibly fine, the problem is a character you cannot see.

A byte-order mark. A file saved as "UTF-8 with BOM" begins with three invisible bytes, and most JSON parsers reject them. This is the single most maddening JSON error, because the document is genuinely correct — copy the text into a fresh file and it parses, which makes the original look haunted. Save without a BOM, or strip the first three bytes.

Non-breaking spaces. Text copied from a web page, a PDF or a word processor can contain U+00A0 where you think there is a space. JSON permits only four whitespace characters between tokens — space, tab, carriage return, line feed — and a non-breaking space is none of them.

Smart quotes. The same sources substitute typographic quotes for straight ones. A curly quote is not a string delimiter; it is just a character, and the parser says so.

Fix: retype the first line, or paste through a plain-text editor. If you suspect an invisible character, a hex view of the first bytes settles it immediately.

There is also the case where the document parses fine and is still wrong, which no parser will help with. A payload that is well-formed but has every field misspelled is valid JSON — see how to validate JSON for what validation does and does not prove.

Worth checking before spending an afternoon on the syntax. Three things arrive labelled as JSON regularly and are not:

A JavaScript object literal. Unquoted keys, single quotes, trailing commas, comments, functions. Everything above, in one document.

JSON5 or JSONC. Deliberate supersets that add comments and relaxed quoting, used for config files. Your editor accepts them because it uses a lenient parser; a strict one will not. Strip the comments or use a parser that expects the dialect.

YAML. If the file has indentation-based structure and key: value lines without braces, it is YAML, and the converter will turn it into JSON. Confusingly, valid JSON is also valid YAML — the relationship only runs one way, which is why a YAML parser accepts your JSON but not the reverse. The comparison explains the overlap.