JSON's Surprisingly Personal Origin Story
JSON.parse throws on a file that looks completely fine: maybe there's a trailing comma, or single quotes around a string, or a key without quotes at all, and the confusing part is that the exact same text would run without complaint as a plain JavaScript object literal. That gap isn't a bug in the parser. It's baked into JSON's history. Most data formats are designed by a committee and published as a spec. JSON's own creator describes it more like a discovery than an invention. And the format didn't get a formal standard until years after it had already taken over.
Noticed, not designed from scratch
Around 2001, Douglas Crockford observed that a subset of JavaScript's own object-literal syntax already worked perfectly as a lightweight, language-independent way to represent structured data. He's described the process less as inventing a new format and more as discovering one that was effectively already sitting inside JavaScript, and simply needed to be named, specified, and popularized. He registered json.org and the format spread through direct developer adoption, well before any formal standards body touched it.
Standardization came years after the format had already won
JSON operated for over a decade as a de facto standard defined mainly by that original informal specification and widespread implementation, rather than an official standards document. Formal standardization arrived much later, ECMA-404 in 2013 and RFC 8259 in 2017. Meaning the format had already become the dominant way web APIs exchange data well before it had an official spec body behind it.
What got deliberately left out
JSON strips out several things that are legal in an actual JavaScript object literal: no comments, no trailing commas, no functions or arbitrary expressions as values, and keys must be double-quoted strings. Those restrictions weren't oversights. They were deliberate simplifications that made JSON trivial to parse correctly and consistently across many different programming languages, which is a large part of why it caught on so broadly.
That's also the exact list of things that trip up a hand-edited JSON file today. A trailing comma after the last item, a comment left in for a future reader, single quotes instead of double, an unquoted key copied straight out of JavaScript: all of it is valid in a JS object literal and all of it is rejected by a strict JSON parser, on purpose. The restriction is what makes JSON parseable the same way in every language; it just means JSON syntax and JavaScript syntax only overlap, they aren't identical.
Why that simplicity mattered competitively
JSON's main rival at the time, XML, requires a substantially heavier parsing and schema apparatus to use correctly. JSON's stripped-down, unambiguous grammar meant a functioning parser could be written quickly and reliably in almost any language, and that ease of implementation is widely credited as the deciding factor in JSON overtaking XML as the default format for web APIs through the 2000s and 2010s.
What to actually do about it
If the goal is fixing a JSON.parse error, check for the four usual suspects first: a trailing comma, single quotes instead of double, an unquoted key, or a comment left in the file, since those are precisely the things JSON deliberately excludes that plain JavaScript allows. If the goal is writing JSON by hand without hitting the error at all, stick to double-quoted keys and strings, no trailing commas, and no comments from the start. And if the goal is turning a JavaScript object literal into valid JSON (or checking whether something already is valid JSON), running it through a formatter that validates as it parses is faster than tracking down the one stray character by eye.
Format, validate, or minify your own JSON with the JSON formatter.