What is JSON? A Complete Guide for Beginners

JSON in 30 Seconds

JSON (JavaScript Object Notation) is a lightweight, text-based data format that's become the lingua franca of data exchange on the web. If you've ever called a REST API, opened a package.jsonfile, or worked with MongoDB, you've already used JSON — probably without giving it much thought.

At its core, JSON is just a way to represent structured data as plain text. It's human-readable (mostly), machine-parseable (very easily), and supported by virtually every programming language in existence. That combination is exactly why it won.

A Brief History

JSON was popularized by Douglas Crockford in the early 2000s. He didn't really "invent" it — the syntax is a subset of JavaScript that had been around since 1999 — but he gave it a name, a website (json.org), and a specification. Sometimes branding matters more than invention.

The format was formally specified in RFC 4627 (2006) and later superseded by RFC 8259(2017) and the ECMA-404 standard. But honestly, the spec hasn't changed much since the beginning. JSON's simplicity is its greatest strength — there just isn't much to change.

Before JSON took over, XML was the dominant data interchange format. If you want to see why developers flocked to JSON, check out our JSON vs XML comparison.

The 6 JSON Data Types

JSON supports exactly six data types. No more, no less. This constraint is intentional — it keeps things simple and interoperable across languages.

Notice what's noton the list: dates, functions, undefined, comments, or binary data. JSON doesn't support any of those natively. Dates are typically passed as ISO 8601 strings ("2025-01-15T10:30:00Z"), and binary data gets Base64-encoded. It's a bit annoying, but it keeps the format universal.

JSON Syntax Rules

JSON's syntax is strict. Coming from JavaScript, you might trip over a few of these rules. Here they are, no sugarcoating:

• Keys must be double-quoted strings.Single quotes don't work. Unquoted keys don't work. This isn't JavaScript.
• Strings must use double quotes. 'hello' is invalid JSON. "hello" is valid.
• No trailing commas. That last comma after the final property? JSON says no.
• No comments.This is probably JSON's most controversial design decision. Douglas Crockford removed them deliberately to prevent abuse.
• No single-value root (in older specs). RFC 8259 now allows any JSON value as the root, but many parsers still expect an object or array.

Here's a valid JSON document:

{
  "name": "Grace Hopper",
  "age": 85,
  "languages": ["COBOL", "FORTRAN"],
  "retired": true,
  "spouse": null,
  "address": {
    "city": "Arlington",
    "state": "VA"
  }
}

And here's what breaks it:

{
  name: "Grace Hopper",     // ❌ Unquoted key
  'age': 85,                // ❌ Single-quoted key
  "languages": ["COBOL",],  // ❌ Trailing comma
  // This is a comment      // ❌ Comments not allowed
}

JSON vs JavaScript Objects

This trips up almost every JavaScript developer at some point. JSON looks like a JS object literal, but they're not the same thing. Here's where they diverge:

In practice, you convert between them with JSON.parse() and JSON.stringify():

// String → Object
const data = JSON.parse('{"name": "Ada", "year": 1843}');
console.log(data.name); // "Ada"

// Object → String
const json = JSON.stringify({ name: "Ada", year: 1843 });
console.log(json); // '{"name":"Ada","year":1843}'

// Pretty-print with 2-space indentation
const pretty = JSON.stringify(data, null, 2);

Common Use Cases

1. REST APIs

This is JSON's bread and butter. The vast majority of modern web APIs send and receive JSON. When you fetch()data from a server, you're almost certainly getting JSON back:

const response = await fetch("https://api.example.com/users/1");
const user = await response.json();
// { "id": 1, "name": "Alice", "email": "alice@example.com" }

2. Configuration Files

package.json, tsconfig.json, .eslintrc.json, composer.json — the list goes on. JSON is everywhere in developer tooling. The lack of comments is genuinely painful here, which is why some tools support JSON5 or JSONC (JSON with Comments) as alternatives.

3. NoSQL Databases

MongoDB stores documents as BSON (Binary JSON). CouchDB uses plain JSON. DynamoDB, Firestore, and countless others use JSON-like structures. If you're working with a document database, you're working with JSON.

4. Local Storage & State Management

Browser localStorage only stores strings, so serializing state to JSON is the standard approach:

// Save
localStorage.setItem("prefs", JSON.stringify({ theme: "dark", lang: "en" }));

// Load
const prefs = JSON.parse(localStorage.getItem("prefs") ?? "{}");

5. Data Exchange Between Microservices

Message queues (RabbitMQ, Kafka), webhooks, and inter-service communication all lean heavily on JSON. It's not always the most efficient choice for high-throughput scenarios (Protobuf and MessagePack are faster), but it's the most debuggable.

JSON Best Practices

After years of working with JSON daily, here are the habits I recommend building:

1. Use consistent naming conventions. Pick camelCase or snake_case for keys and stick with it across your API. Mixing them is a fast track to bugs.
2. Validate early.Don't trust incoming JSON blindly. Use JSON Schema validation to catch malformed data before it hits your business logic.
3. Keep nesting shallow. If your JSON is more than 3-4 levels deep, consider flattening it. Deeply nested structures are hard to query, hard to read, and hard to diff.
4. Use arrays for lists, objects for records.Sounds obvious, but I've seen people use objects with numeric string keys ({"0": "a", "1": "b"}) instead of arrays. Don't do that.
5. Prefer null over missing keys when a field has no value. It makes the schema explicit and avoids ambiguity about whether a field was intentionally omitted.
6. Format for humans during development. Minified JSON saves bytes but kills readability. Use pretty-printing when debugging, minify when shipping. Our JSON Minifier handles the latter.

What About JSON5 and JSONC?

If JSON's strictness bothers you, you're not alone. Two popular extensions relax the rules:

• JSON5allows single-quoted strings, trailing commas, comments, unquoted keys, and more. It's great for config files where humans are the primary audience.
• JSONC (JSON with Comments) is a minimal extension used by VS Code and TypeScript configs. It adds only comment support — nothing else.

Neither of these is valid JSON, though. If you're building an API or exchanging data between systems, stick with standard JSON. Use extensions only where the tooling explicitly supports them.

Wrapping Up

JSON succeeded not because it's perfect, but because it's good enough for nearly everything and dead simple to work with. Its limited type system is frustrating at times (where are my dates?), and the no-comments rule is a genuine pain point. But those constraints are also what make it universally interoperable.

If you're just getting started, the best way to learn JSON is to work with it hands-on. Try pasting some data into our tools, break things on purpose, and see what happens. Understanding the error messages is half the battle.

Keep exploring:

• JSON vs YAML — when to use each format
• JSON vs XML — why JSON replaced XML for most use cases
• JSON Validator — check if your JSON is valid
• JSON Schema Generator — automatically generate schemas from JSON data