
"Unexpected token," "Unexpected end of JSON input," or a config file that mysteriously refuses to load — invalid JSON errors are cryptic, but the causes are not. In practice, the same seven mistakes account for nearly every broken JSON file, and most of them exist because JSON looks deceptively like JavaScript while being far stricter.
This guide lists all seven with before-and-after examples, so you can diagnose by eye. And when a file is too big to eyeball, paste it into the free Toolyfied JSON formatter — it validates the syntax, points at the failing spot, and pretty-prints the result in one step, with no sign-up.
Why JSON Is Stricter Than It Looks
JSON was carved out of JavaScript's object syntax, but the specification deliberately dropped every convenience. A JavaScript object literal tolerates single quotes, unquoted property names, trailing commas, and comments; JSON allows none of them. That gap is the root of most invalid JSON: people hand-write JSON the way they write JavaScript, and the parser refuses it.
Keep one rule in mind and half the errors disappear: in JSON, all strings and all keys use double quotes, and nothing optional is allowed. Everything below is a specific violation of that rule or of JSON's bracket-matching structure.
The 7 Most Common JSON Errors (Before and After)
Here they are, roughly in order of how often they bite:
- 1. Trailing commas — a comma after the last item, like {"a": 1, "b": 2,} or [1, 2, 3,]. JavaScript shrugs; JSON fails. Fix: delete the final comma so it reads {"a": 1, "b": 2}.
- 2. Single quotes — {'name': 'Ana'} is invalid. JSON strings and keys must use double quotes: {"name": "Ana"}.
- 3. Unquoted keys — {name: "Ana"} works as a JavaScript literal but not as JSON. Every key needs quotes: {"name": "Ana"}.
- 4. Mismatched or missing brackets — an unclosed { or [ usually surfaces as "unexpected end of JSON input." Fix: pretty-print the document so indentation reveals which block never closes.
- 5. Bad escapes and control characters — a literal backslash in a Windows path like "C:\temp" must be doubled ("C:\\temp"), inner double quotes need escaping ("say \"hi\""), and real line breaks inside a string must become \n.
- 6. Comments — JSON has no comment syntax, so // notes and /* blocks */ that sneak in from config-file habits invalidate the file. Remove them or move that data into a real key.
- 7. Wrong value literals — True, FALSE, None, undefined, or NaN are not JSON. The only bare literals are lowercase true, false, and null; anything else must be a number or a quoted string.
How to Read a JSON Parse Error Message
Error messages like "Unexpected token ' in JSON at position 47" are more helpful than they look. The token is the character the parser choked on, and the position is a character offset from the start of the file. An unexpected single quote means error #2 above; an unexpected } or ] right after a comma means a trailing comma; "unexpected end of input" almost always means an unclosed bracket or quote.
One subtlety: the reported position is where the parser gave up, not necessarily where the mistake lives. A quote you forgot to close on line 3 might not produce an error until line 40, when the parser finally hits something impossible. That is why the practical debugging move is not staring at the reported line, but validating and pretty-printing the whole document so the structural break becomes visible.
Validate and Pretty-Print JSON Online in Seconds
For anything longer than a dozen lines, let a tool do the hunting. Paste your document into the free JSON formatter: if the JSON is valid, it pretty-prints instantly with consistent indentation; if not, you get the parse error so you can fix the offending spot and re-check. The edit-validate loop takes seconds, requires no account, and beats manually counting braces every time.
Pretty-printing is diagnostic power, not just cosmetics. Minified, single-line JSON hides structure; once formatted, each nesting level gets its own indentation, so a missing bracket or misplaced comma stands out visually. It is worth formatting API responses before reading them even when they are valid.
Fixing JSON is also worth doing before conversion work. If you are transforming data anyway, a validated file feeds cleanly into the JSON to Excel converter for spreadsheet analysis, and data coming from spreadsheets via the CSV to JSON converter arrives already valid — machine-generated JSON never has these syntax problems; only hand-edited JSON does.
Habits That Prevent Invalid JSON
A few habits eliminate these errors at the source. Never hand-edit JSON in a plain notepad app — use an editor with syntax highlighting, which colors strings and flags mismatched quotes as you type. Validate after every manual edit, not just when something breaks downstream. When editing a config file, change values rather than structure whenever possible. And if you find yourself repeatedly writing JSON by hand, generate it instead: exporting from the actual data source is always safer than typing braces.



