What if I told you there's a data format so small you can learn its entire grammar in one sitting — and it happens to be the format nearly every API on the internet speaks? Meet JSON.

What JSON is, and why it won

JSON (JavaScript Object Notation) is a plain-text way to describe structured data. It started life inside JavaScript, but it escaped long ago: today it's completely language-neutral. C#, Python, Java, Go — everything reads and writes it.

Why did it beat the older, heavier formats? Two reasons. It's human-readable — you can open a JSON response and just see what's in it. And it's tiny to learn: the whole format is built from only six kinds of values.

The six value types

object array string number true / false null
  • Object — curly braces holding "key": value pairs. The workhorse.
  • Array — square brackets holding an ordered list of values.
  • String — text in double quotes: "Margherita".
  • Number — 42 or 12.5. No quotes.
  • Boolean — exactly true or false.
  • Null — null, meaning "deliberately nothing here."

Here's the elegant part: objects and arrays can hold any value type — including other objects and arrays. That nesting is how six simple pieces describe anything from a pizza order to a spacecraft telemetry feed.

One example with everything in it

Let's order a pizza. Every one of the six types appears below — see if you can spot them all:

{
  "id": 42,
  "customer": "Priya",
  "delivery": true,
  "coupon": null,
  "address": {
    "street": "12 Baker Lane",
    "city": "Springfield"
  },
  "pizzas": [
    { "name": "Margherita", "size": "large", "toppings": ["basil", "extra cheese"] },
    { "name": "Veggie Supreme", "size": "medium", "toppings": [] }
  ]
}

Reading it top to bottom: the whole thing is an object. id is a number, customer a string, delivery a boolean, and coupon is null — the customer could have one but doesn't. address is a nested object, and pizzas is an array of objects, each with its own toppings array (the second one empty — plain cheese, no judgment).

The mistakes that trip up beginners

JSON looks forgiving, but its parser is strict. Nearly every "invalid JSON" error comes from one of these four habits (usually carried over from JavaScript or Python):

  • Single quotes. 'name' is invalid — JSON strings and keys require double quotes: "name".
  • Trailing commas. A comma after the last item in an object or array breaks the whole document.
  • Comments. There are none! That's why I explained the example above in a paragraph instead of inline — JSON has no comment syntax at all.
  • Unquoted keys. { id: 42 } works in JavaScript, but JSON demands { "id": 42 }.

Tip: When JSON misbehaves, paste it into a validator (search "JSON validator" — there are many free ones) or your editor's JSON mode. It will point at the exact character where things went wrong.

JSON in practice

You'll meet JSON in two main places. APIs: when your app asks a server for data, the answer is almost always JSON. Configuration files: many tools store their settings as JSON, so being fluent pays off even before you write a line of server code.

Programs don't work with JSON text directly — they parse it into real objects in their own language. In C# it's one line: 

var order = JsonSerializer.Deserialize<PizzaOrder>(json);

After that, order.Customer and order.Pizzas are ordinary C# properties with full type checking. Going the other way — object to JSON text — is called serializing, and it's just as easy.

Note: Because JSON keys are always strings and structure is flexible, two systems can exchange data without sharing any code — they only need to agree on the shape. That loose handshake is a big part of why the modern web fits together at all.

And that's genuinely the whole language — six value types, four gotchas, done. You'll never look at an API response with confusion again. Next step: watch JSON doing its day job in REST APIs explained with a pizza shop, or zoom out and follow a request's full journey in what happens when you type a URL.