Why JSON?
Picture two computers that have never met, written in two different languages, trying to exchange information. They can't share memory, they can't share objects, they can't even agree on what a "string" looks like at the byte level. What they can agree on is text. JSON — JavaScript Object Notation — is a small, strict way of writing data as text so that any program in any language can read it the same way.
💡 The Bottom Line
JSON exists to solve one problem: getting structured data from one program to another, reliably, regardless of what language either program is written in. It won because it's small, human-readable, and maps directly onto the data structures — objects and arrays — that almost every modern language already has.
Born from JavaScript, adopted by everyone
JSON's syntax is literally a subset of JavaScript's object-literal syntax — that's where the name comes from. Douglas Crockford popularized it in the early 2000s as a lightweight alternative to XML for sending data between a web browser and a server. The pitch was simple: instead of a verbose, tag-heavy XML document, just send something that already looks like the JavaScript object the browser was going to build anyway.
🙋 There Are No Dumb Questions
Q: Does JSON only work with JavaScript, then?
A: No — despite the name, JSON is language-agnostic. Python, Java, C#, Go, Ruby, PHP,
literally every mainstream language has a built-in or standard-library way to read and write
JSON. The "JavaScript" in the name is about its syntax origin, not a restriction on who can
use it.
Why it beat XML for most jobs
XML was the dominant data-interchange format before JSON. JSON won the popularity contest for a few concrete reasons:
- Less punctuation — no closing tags to repeat, no separate attribute syntax to learn.
- Maps directly to data structures — a JSON object is a dictionary/map/hash; a JSON array is a list. XML's tree-of-elements-with-attributes shape needs an extra mental translation step.
- Smaller payloads — less markup overhead means less data to send over the network, which matters at scale.
XML isn't gone — it's still common in enterprise systems, RSS feeds, and anywhere documents (not just data) need markup — but for APIs and configuration, JSON became the default.
⚠️ Watch Out
JSON is not a full replacement for every job XML did. JSON has no built-in way to add comments, no schema language as mature as XML Schema (though JSON Schema exists — see Lesson 5), and no native support for mixed content (text interleaved with markup, the way HTML does it). For pure data interchange, though, it's simpler and has mostly won.
Where you'll actually meet JSON
🌐 APIs
Almost every REST API request and response body today is JSON.
⚙️ Config files
package.json, tsconfig.json, and countless tool configs.
💾 Storage
NoSQL databases like MongoDB store documents in a JSON-like format natively.
📨 Message queues
Services that don't share a language still need to pass structured messages — JSON is the common tongue.
🔧 Try It Yourself
Open your browser's developer tools (F12), go to the Network tab, and visit almost any modern website. Click on a request and look at the response. There's a very good chance you'll see JSON — that's the data the page used to render what you're looking at.
✅ Quick Check
What's the main reason JSON became more popular than XML for APIs?
Next up: JSON's actual syntax rules — the small, strict set of data types and formatting rules that make it so easy for any parser to read.