JSON looks almost exactly like a JavaScript object literal, which is precisely why it trips people up — it isn't one. JSON (JavaScript Object Notation) is a strict, standalone data format with its own grammar, and that grammar is noticeably less forgiving than JavaScript itself. Most "invalid JSON" errors trace back to a small set of rules that JavaScript relaxes but JSON enforces.
The rules JSON actually enforces
Keys must be double-quoted strings. {name: "Alex"} is valid JavaScript but invalid JSON — it must be {"name": "Alex"}. Single quotes aren't allowed either, for keys or values.
No trailing commas. {"a": 1, "b": 2,} is invalid — that trailing comma after the last value breaks strict JSON parsers, even though it's harmless in JavaScript and even encouraged in some style guides.
No comments. JSON has no comment syntax at all — neither // nor /* */. This surprises people because so many "JSON" config files (like tsconfig.json in practice) informally support comments via a lenient parser, but that's a JSONC/JSON5 extension, not standard JSON.
No undefined, NaN, or Infinity. These are valid JavaScript values but have no JSON representation. undefined keys are typically just dropped when serializing; trying to represent them explicitly in JSON text is invalid.
Strings must use double quotes, and backslashes must be escaped. A literal backslash in a JSON string must be written as \\; an unescaped one is a parse error.
Numbers can't have leading zeros or a leading plus sign. 007 and +5 are both invalid JSON numbers.
Why "beautifying" JSON matters beyond looks
Minified JSON (all on one line, no whitespace) is common in API responses because it saves bandwidth, but it's nearly impossible to debug by eye — a missing bracket or misplaced comma is invisible in a wall of text. Beautifying (pretty-printing) JSON adds consistent indentation and line breaks so the structure becomes visually obvious, which is usually the fastest way to spot exactly where a document breaks: the formatter itself will often point at the offending line when it fails to parse.
Minifying, the reverse operation, matters when you're about to actually transmit or store the JSON — stripping whitespace can shrink a deeply nested document noticeably, especially if it was hand-formatted with wide indentation.
A quick mental checklist for JSON errors
When a validator reports an error and the line number doesn't obviously point at the problem, check these in order: unquoted or single-quoted keys, a trailing comma before a closing } or ], an unescaped backslash or unescaped double-quote inside a string, and a stray comment left in from copy-pasting a JavaScript object. These four cover the overwhelming majority of "why won't this parse" reports.
Try it
GlaeKit's JSON Formatter beautifies, minifies, and validates JSON entirely in your browser, with clear error messages when something doesn't parse — nothing you paste in ever leaves your device.
Frequently asked questions
Why does my valid JavaScript object fail as JSON?
JavaScript object literal syntax is more permissive than JSON — it allows unquoted keys, single-quoted strings, trailing commas, and comments, none of which are valid in strict JSON. Copy-pasting a JS object directly as JSON is one of the most common sources of parse errors.
Can JSON have comments?
No, standard JSON has no comment syntax. Some tools accept a relaxed superset (often called JSON5 or JSONC) that adds comments, but that's not valid JSON and will fail in a strict parser.
Is a trailing comma really invalid in JSON?
Yes — unlike JavaScript, which tolerates a trailing comma after the last item in an array or object, standard JSON treats it as a syntax error.
What's the difference between minifying and beautifying JSON?
Beautifying adds indentation and line breaks to make the structure readable for humans; minifying strips all unnecessary whitespace to make the payload as small as possible for transmission. Both represent the exact same data — only the formatting differs.