What is JSON? A Complete Guide for Developers

If you've been writing code for more than a week, you've almost certainly run into JSON. It shows up everywhere — REST API responses, config files, database documents, browser storage, logs. But what exactly is it, and why did it become the format that ate the web?

JSON stands for JavaScript Object Notation. Despite the name, it's completely language-independent and has libraries in every major programming language. Douglas Crockford formalized it in the early 2000s as a simpler alternative to XML for browser–server communication. The spec is also standardised as ECMA-404, and it's so small it fits on a business card — which is part of why it won.

What Does JSON Actually Look Like?

Here's a JSON snippet that represents a user object. This single example covers all six data types JSON supports:

{
  "name": "Alice",
  "age": 30,
  "score": 98.5,
  "active": true,
  "nickname": null,
  "tags": ["developer", "blogger"],
  "address": {
    "city": "Berlin",
    "country": "Germany"
  }
}

The Six JSON Data Types

JSON supports exactly six value types. That's it. This simplicity is a feature — you can learn the entire format in an afternoon.

{
  "string":  "Hello, world",
  "integer": 42,
  "float":   3.14159,
  "boolean": true,
  "nothing": null,
  "array":   [1, "two", false, null],
  "object":  { "nested": true }
}

• String — Any text in double quotes. "hello", "2024-01-01", "" are all valid strings.
• Number — Integer or floating point. No distinction between int and float. Note: NaN and Infinity are not valid JSON numbers.
• Boolean — true or false, lowercase only.
• Null — Represents "no value". Useful for optional fields that haven't been set.
• Array — An ordered list of values. Can mix types: [1, "two", true, null] is perfectly legal.
• Object — A set of key–value pairs. Keys must be strings in double quotes.

A Real-World API Response

Here's what a real REST API response might look like when you call GET /api/users/42. Notice how it nests objects and arrays to represent richer data:

{
  "id": 42,
  "username": "alice_dev",
  "email": "[email protected]",
  "createdAt": "2023-06-15T09:30:00Z",
  "preferences": {
    "theme": "dark",
    "notifications": true,
    "language": "en"
  },
  "roles": ["user", "editor"],
  "lastLogin": "2024-01-10T14:22:00Z",
  "stats": {
    "postsPublished": 27,
    "commentsWritten": 154,
    "likesReceived": 489
  }
}

You could access alice_dev's theme preference in JavaScript with user.preferences.theme, or get her first role with user.roles[0]. That natural mapping to language primitives is exactly why JSON feels so effortless to work with.

JSON Syntax Rules — The Gotchas That Bite Everyone

JSON looks simple but has a few strict rules. Get one wrong and your entire payload fails to parse. These are the mistakes I see most often:

• Keys must be double-quoted. {"name": "Alice"} is valid. {name: "Alice"} is not. This trips up developers coming from JavaScript where unquoted object keys are fine.
• No trailing commas. {"a": 1, "b": 2,} will throw a parse error. JavaScript is forgiving here; the JSON spec is not.
• No comments. // or /* */ comments don't exist in JSON. If you need commented config files, consider YAML or TOML instead.
• No undefined. JavaScript's undefined doesn't exist in JSON. Use null for missing values.
• Strings must use double quotes. Single-quoted strings like {'key': 'value'} are invalid JSON.
• No leading zeros. 042 is invalid. 42 or 0.42 are fine.

Why JSON Won the Web

Before JSON, XML was king. A typical XML API response was verbose, required a proper XML parser, and felt like working against the language. JSON could be parsed by JavaScript's built-in JSON.parse() — no libraries needed. It was smaller on the wire, readable at a glance, and mapped directly to the objects and arrays developers already used every day.

By the late 2000s, most public APIs started offering JSON alongside XML. By the early 2010s, many dropped XML support entirely. Today, the default assumption for any REST API is JSON. Even GraphQL, which replaced REST in many contexts, still uses JSON as its response format.

JSON Is Also Defined by What It Doesn't Support

Some of JSON's limitations are intentional design choices that keep it simple and interoperable:

• No date type. Dates are just strings. The convention is ISO 8601 format: "2024-01-15T09:30:00Z".
• No binary data. Files and images are typically Base64-encoded into a string.
• No function values. {"fn": function(){} } is invalid. JSON is pure data, never code.
• No duplicate keys. Technically allowed by the spec but behaviour is undefined. In practice, parsers take the last value.

Useful Tools for Working with JSON

Here are some tools you'll reach for constantly when working with JSON: JSON Formatter to pretty-print minified responses, JSON Validator to find syntax errors, JSON Minifier to compress JSON for production, and JSON Path to query deeply nested data without writing loops.

The official spec lives at json.org and is genuinely worth reading — it takes about 10 minutes and you'll understand the format completely. The IETF formal spec is RFC 8259 if you ever need to settle a debate.

Wrapping Up

JSON is a lightweight, human-readable data format built on six value types: strings, numbers, booleans, null, arrays, and objects. It has strict syntax rules but no surprises once you know them. The reason it became ubiquitous isn't because it's the most powerful format — it's because it's the simplest one that covers 95% of real-world data needs. If you're building anything web-related, understanding JSON isn't optional. It's foundational.