Common JSON Syntax Errors and How to Fix Them

The single most common mistake is a trailing comma — a comma after the last item in an object or array, like {"a": 1, "b": 2,}. Many programming languages allow this, but JSON does not, so parsers reject it. The mirror image is a missing comma between two items, which also fails. When you format a document and it breaks near a closing brace or bracket, a stray or absent comma is the first thing to check.

Editors make this easier than it used to be: most highlight the offending comma as you type, and a formatter removes it automatically when it rewrites the document. If you maintain a long list by hand, a habit worth adopting is to add new entries above the last one rather than after it, so the final line — the one that must not end in a comma — stays untouched.

JSON requires double quotes around every key and every string value. Single quotes ('like this') are invalid, even though they are perfectly normal in JavaScript and Python. Unquoted keys — writing name instead of "name" — fail for the same reason. If you copied an object literal out of source code, converting the quotes is usually all it takes to make it valid JSON.

A related trap is smart quotes. Pasting from a word processor or chat app can silently swap straight quotes for curly “typographic” ones, which parsers do not accept. If a string looks correct but still fails, retype the quotes by hand.

Certain characters inside a string must be escaped with a backslash: a literal double quote becomes \", a backslash becomes \\, and newlines or tabs become \n and \t. Forgetting to escape a quote inside a string is a frequent cause of failures in generated JSON. Watch too for values JSON does not allow — comments, NaN, Infinity or an undefined value — all of which come from other languages and must be removed or converted.

The forward slash is a small special case that goes the other way: \/ is legal and means exactly the same as /, a relic of embedding JSON inside HTML script tags. You will still see escaped slashes in output from PHP and older libraries. They are harmless, and a formatter normally leaves them as it found them.

The validator reports the position of the first failure, so work top to bottom: fix the earliest error, revalidate, and repeat. Often a single missing bracket explains a whole cascade of complaints.

Error messages look cryptic but are unusually literal. "Unexpected token } in JSON at position 41" means the parser reached character 41 and found a closing brace where a key or a value was required — almost always a trailing comma just before it. "Unexpected end of JSON input" means the document ran out while a brace, bracket or quote was still open: the content was truncated, or a closing character is missing. "Unexpected non-whitespace character after JSON" means there are two documents where one was expected.

One message deserves special mention because it fools people daily: "Unexpected token < in JSON at position 0". A less-than sign at the very start means the response was not JSON at all — it was HTML, usually an error page, a login redirect or a proxy notice. No amount of fixing the JSON will help; check the status code and the raw response body instead.

Hand-typed JSON is rarely the problem. Most invalid documents are generated: a template that builds JSON by concatenating strings and forgets to escape a user-supplied quote; a log line cut off at a buffer boundary; a copy out of a terminal that wrapped and inserted a line break inside a string. Building JSON with your language's serialiser instead of string concatenation removes the entire category at once.

Two invisible culprits are worth knowing. A byte-order mark at the start of a UTF-8 file shows as nothing in an editor but makes the first character unexpected to a strict parser, so strip it when reading files written on Windows. And raw control characters — a real tab or newline pasted inside a string instead of \t or \n — are rejected even though the text looks perfectly fine on screen.