Home · Blog · JSON basics

JSON for beginners: the format that runs the web

11 Oct 2026 · Data · 7 min read

Every time a weather app shows you a forecast, a shop website lists its products, or a login form talks to a server, there is a very good chance the data travelled as JSON. It stands for JavaScript Object Notation, but don't let the name put you off: despite its origins, JSON is understood by virtually every programming language in use today, and you don't need to be a programmer to read it.

At its heart, JSON is just a way of writing down structured data as text so that both humans and machines can read it. A person's name and age, a list of products with prices, the settings of an app — all of these fit naturally into JSON's two containers. This article walks through those containers, the handful of value types, the syntax rules that catch out every beginner exactly once, and the format's honest limitations.

Objects and arrays: the only two containers

Everything in JSON is built from two structures. An object is a collection of named values — think of it as a labelled filing box. Each label (called a key) is paired with a value:

{
  "name": "Ada Lovelace",
  "born": 1815,
  "mathematician": true
}

An array is an ordered list of values, written in square brackets:

["red", "green", "blue"]

The real power comes from nesting them inside each other. A bookshop order might look like this:

{
  "order_id": 1042,
  "customer": "Priya Sharma",
  "items": [
    {"title": "The Left Hand of Darkness", "price": 12.99},
    {"title": "Kindred", "price": 11.50}
  ],
  "gift_wrap": false
}

Read it inside out: the order is an object; its "items" value is an array; each element of that array is an object describing one book. Once you can see the nesting, you can read any JSON document, no matter how deep it goes.

The six value types

JSON is deliberately small. There are exactly six kinds of value, and they cover a surprising amount of ground:

A few subtleties are worth knowing early. Numbers never wear quotes: 42 is a number, "42" is a string that happens to contain digits, and mixing them up is a classic source of bugs. null means "this field exists but has no value" — different from the field being absent entirely, and very different from the string "null". And there is no date type: dates are written as strings by convention, usually in ISO 8601 form like "2026-10-11T07:30:00Z", which every language can parse.

The five syntax rules that trip everyone up

JSON's grammar fits on an index card, yet almost everyone stumbles on the same five points when they first write it by hand:

1. Double quotes only. Strings and keys must use ", never '. {'name': 'Ada'} is not JSON, however reasonable it looks.
2. No trailing commas. ["a", "b",] is invalid. That comma after the last item — the one your instincts keep adding — will break the whole document.
3. No comments. There is no // or # in JSON. If you want to annotate something, add a field like "_comment": "...".
4. One value per document. A JSON document is a single value — one object, one array, one string. Two objects back to back is not valid JSON.
5. Commas between items, colons between keys and values. {"a" = 1} or {"a": 1; "b": 2} will both fail. The punctuation is small but unforgiving.

Nearly every "my JSON doesn't work" story in history is one of these five. When a parser rejects your file, check this list before anything else.

A worked example: reading a weather response

APIs — the services apps talk to — usually answer in JSON. Here is a shortened version of what a weather service might return for a city:

{
  "city": "Lahore",
  "temperature_c": 31,
  "conditions": "hazy sunshine",
  "humidity_pct": 58,
  "forecast": [
    {"day": "Thu", "high_c": 32, "low_c": 21},
    {"day": "Fri", "high_c": 33, "low_c": 22},
    {"day": "Sat", "high_c": 31, "low_c": 20}
  ]
}

To find Saturday's low, you walk the structure: the top-level object has a "forecast" key whose value is an array; the third element (index 2, since counting starts at zero) is an object; its "low_c" is 20. That's all "parsing JSON" means at the human level — following the nesting like a set of directions.

Where JSON came from

JSON was specified in the early 2000s by Douglas Crockford, who noticed that the object notation already built into JavaScript made an excellent data format on its own. He wrote it down as a tiny, strict subset — and strictness was the point. Earlier formats like XML were powerful but verbose and fiddly; JSON's minimalism meant a parser could be written in an afternoon and a human could read the output without a manual. Within a decade it had quietly become the default language of web APIs, and it has held the position ever since.

JSON in the wild: configuration files

Beyond APIs, JSON's second career is configuration. Open almost any modern software project and you'll find files like package.json or tsconfig.json describing how the project builds, and countless apps keep their settings as JSON. The reasons are the same ones that made it win APIs: every language reads it, humans can edit it, and diffs in version control stay clean and reviewable.

The no-comments rule chafes hardest here, which is why two unofficial dialects exist: JSONC (JSON with Comments), used by editors like VS Code, and JSON5, which additionally allows trailing commas and single quotes. They're conveniences for humans, not standards — a strict JSON parser will reject both. If a tool says it wants JSON, give it strict JSON; the dialects are only safe where explicitly supported.

Reading deeply nested data without getting lost

Real-world JSON is often five or six levels deep, and beginners get lost around level three. The technique is mechanical: follow the brackets. Each { opens a named level, each [ opens a numbered one, and you read the path aloud — "response, then results, then item 0, then address, then city." Paste the document into a formatter (like the one linked below) and the indentation does the visual work for you: each level steps right, and matching brackets line up vertically. When an API's documentation says a value lives at data.forecast[2].low_c, it's just writing out that spoken path in shorthand — dots for object keys, brackets for array positions.

The honest limits

JSON's simplicity is also its boundary, and it's worth knowing where the edges are before you lean on it too hard. The lack of comments makes it a mediocre format for configuration files that humans maintain — which is partly why formats like YAML and TOML exist. The lack of a date type means every project invents its own convention, and mixing conventions ("11/10/2026" — is that October 11th or November 10th?) causes real bugs. Very large integers can lose precision in some languages because JSON numbers are typically read as floating point; IDs longer than about 15 digits are safer as strings. And for truly massive or high-speed data, binary formats are far more compact — JSON's readability costs bytes, roughly two to three times what a packed binary encoding would use.

None of this stops JSON being the right default for most data exchange. It just means that when something feels awkward — commenting a config, comparing two files byte-for-byte after sorting keys, or stuffing a 20-digit ID into a number — the awkwardness is the format telling you its limits, not you doing it wrong.

Try the JSON Formatter