Discovered, Not Invented: The Quietly Strange Story of JSON

There is a fair chance that in the time it takes you to read this sentence, a few billion little bundles of curly braces will have crossed the internet. JSON is the quiet courier of the modern web — the thing your weather app, your bank, your video game, and your smart fridge all speak when they need to pass each other a scrap of information. And yet the whole format is simple enough to sketch on a napkin. That combination — globally dominant, yet almost trivially small — is exactly what makes its backstory so much fun.

Discovered, not invented

Ask Douglas Crockford, the man most associated with JSON, and he'll tell you something slightly cheeky: he didn't invent it. He discovered it. His point is that the building blocks were already sitting inside JavaScript in the form of object literals — curly braces, key–value pairs, square-bracketed arrays. Nobody had to design a new syntax. The shape was already there, lying around in the language, waiting for someone to notice it could be used to ship data between programs.

In 2001, working at a small company called State Software, Crockford and his colleagues started using these plain JavaScript objects to pass data between a browser and a server. They gave the idea a name — JavaScript Object Notation — registered json.org, and wrote up the grammar. That grammar is so compact that the entire specification fits on a single page, illustrated with a handful of little railroad diagrams. There's no version number creep, no sprawling appendix. Six types, a few punctuation marks, done.

It's worth pausing on how unusual that is. Most foundational technologies grow into thick manuals. JSON went the other way. Its power comes precisely from what it refuses to include.

There's a nice irony buried in the name, too. JSON stands for JavaScript Object Notation, yet it long ago outgrew the language it came from. Today it's parsed effortlessly by Python, Rust, Go, Java, C#, Swift, and very nearly everything else — to the point where calling it "JavaScript" anything feels like a historical accident. It's a bit like how the "@" sign was a forgotten accounting symbol until email gave it a second life. JSON borrowed JavaScript's syntax and then quietly became everyone's.

The licence joke that turned out to be serious

Here's the detail that delights every programmer who hears it for the first time. When Crockford released his reference JSON tools, he attached a software licence that was mostly standard boilerplate, except for one extra sentence:

"The Software shall be used for Good, not Evil."

It was a joke — a wink in the middle of dry legal text. The trouble is that lawyers are paid not to laugh. Large companies with strict compliance rules suddenly couldn't use the code, because no corporate legal department can promise its software will never be used for "evil." The most famous case involves IBM, whose lawyers reportedly reached out for clarification. Crockford's response has become a piece of programming folklore: he granted IBM written permission to use the software for evil, adding that they could let their customers use it for evil too. It's the kind of true story that sounds invented, and it captures the slightly mischievous spirit of JSON's early days.

The format that quietly won a war

To appreciate JSON, you have to remember what it replaced. In the early 2000s, the serious, grown-up way to exchange data was XML, often wrapped in heavyweight protocols like SOAP. XML is powerful and verbose; describing a simple list of names could balloon into a thicket of opening and closing tags, namespaces, and schemas. It was built for documents, and people were bending it to carry data.

Then came the rise of AJAX — web pages quietly fetching information in the background to feel more like apps. Developers wanted something lighter to send over the wire, something a browser could turn back into usable data without a parsing library and a strong coffee. JSON fit perfectly. A browser could read it almost natively, it was small, and a human could glance at it and simply understand it. No tags, no ceremony.

There was no committee, no marketing budget, no launch event. JSON spread the way good tools usually do: one developer showed another, who showed another. Within a decade the XML-versus-JSON "war" was effectively over for everyday web APIs, and JSON had become the default. XML didn't vanish — it's still excellent for documents — but for passing data between services, the napkin-sized format won.

The things JSON deliberately leaves out

Newcomers often trip over what JSON won't let them do, and assume these are oversights. They're not. They're decisions.

No comments. You cannot write // note to self inside JSON. People are frequently surprised, even annoyed, by this. Crockford removed comments on purpose. He has explained that he saw developers using comments to smuggle in parsing directives — little instructions that would make one program's JSON behave differently from another's, quietly breaking the universal compatibility that made the format valuable. By stripping comments out, he kept JSON dumb in the best possible way: pure data, no hidden instructions.

No trailing commas. Write [1, 2, 3,] and JSON rejects it, even though most programming languages happily allow that dangling comma. It's a common stumble, especially when you delete the last item in a list and forget the comma above it.

No date type. JSON has strings, numbers, booleans, null, objects, and arrays — and that's the entire universe. There is no native date. By convention everyone agrees to write dates as text in the ISO 8601 format, but the format itself shrugs and treats them as ordinary strings.

Each omission keeps the grammar tiny, and a tiny grammar is what lets any language on earth implement JSON the same way.

The number trap

If JSON has a genuinely sharp edge, it's numbers. On paper, the specification is generous: a JSON number is just a decimal, with no stated limit on how big or precise it can be. In practice, almost every parser on the planet reads those numbers into a 64-bit floating point value — the IEEE 754 "double" — because that's what JavaScript uses.

That has a consequence that has bitten countless developers. Doubles can only represent whole numbers exactly up to 2^53, a little over nine quadrillion. Go beyond that and your perfectly valid-looking integer can silently change value when it's parsed. This is the reason big platforms learned to be careful. Services like X (Twitter) and Discord generate enormous numeric IDs, and they deliberately send those IDs as strings in their JSON, precisely so a careless parser doesn't round someone's unique ID into a neighbour's. The same model also forbids NaN and Infinity, which JavaScript has but JSON refuses to acknowledge.

None of this makes JSON broken. It makes it a format with rules worth knowing — and a good reason to lean on tooling rather than eyeballing a giant payload and hoping.

Frozen on purpose

Eventually the world's most popular data format needed an official rubber stamp. JSON got two. In 2013 it was standardised as ECMA-404, one of the shortest standards you'll ever encounter — it essentially just draws the grammar and steps back. In 2017 the internet's standards body published RFC 8259, tidying up details like requiring UTF-8 for data exchanged between systems.

The most charming thing about ECMA-404 is its stated philosophy: it explicitly promises not to change the grammar. No new features, no evolution, no JSON 2.0. The format is intentionally frozen so that something written today will parse identically in fifty years. In a field obsessed with version numbers and breaking changes, JSON's superpower is that it simply stopped.

That hasn't stopped humans from wanting more. Friendlier supersets exist — JSON5 and JSONC add comments, trailing commas, and other conveniences for files that people edit by hand, like configuration. But they are deliberately not JSON. Feed them to a strict parser and they fail, which is the whole point: the strict core stays pristine, and the cosy variants live next door.

Why strictness is a gift

It's tempting to wish JSON were more forgiving — to let the comma slide, to allow that comment. But the rigidity is exactly what makes it trustworthy. Because the grammar is so small and so unyielding, a parser can give you a definitive answer: this is valid, or this is not, and the problem is right here at this character. There's no ambiguity to negotiate, no "well, it depends." That precision is why a JSON validator can point a caret at the single misplaced quote in a thousand-line file and tell you in plain language what went wrong. Forgiving formats can't do that; they paper over mistakes until the mistakes surface somewhere far away and far less convenient.

So the next time a wall of braces flies past — in a network tab, a log file, a config you're half-afraid to touch — it's worth a small nod of respect. It's a format someone claims he merely found, licensed with a joke that a corporation took seriously, stripped of every feature that might cause trouble, and then frozen forever so the whole world could keep agreeing on it. Not bad for something you could fit on a napkin.