JSON Explained: Why It Became So Popular

A short history

JSON began as a practical interchange format, not an academic standards project. Douglas Crockford documented it at json.org and argued that a small, predictable grammar would beat heavier XML stacks for many web use cases. ECMA-404 and IETF RFC 8259 later codified the same rules: UTF-8 text, objects and arrays, and a fixed set of value types. That standardization mattered because APIs are contracts—every client must parse the same bytes the same way.

JSON is a light-weight, text-based, language-independent data interchange format.

— RFC 8259

What JSON syntax actually allows

At the top level, JSON is either an object or an array. Objects are unordered maps from strings to values; arrays are ordered lists. Keys must be double-quoted strings. Strings use double quotes and standard escape sequences (\", \\, \b, \f, \n, \r, \t, \uXXXX). Numbers are written in decimal; booleans are true and false; null is a first-class value. That is the entire type system—no dates, no comments, no undefined, no trailing commas in strict JSON.

{
  "title": "JSON Explained",
  "published": "2026-10-04",
  "featured": true,
  "tags": ["api", "data"],
  "metrics": { "views": 1204, "rating": 4.8 },
  "notes": null
}

The date and nested metrics are conventions your API documents—not built-in JSON types. JSON only knows string, number, boolean, null, object, and array.

Objects, arrays, and primitives in practice

• Objects group named fields—typical for records, settings, or API resources.
• Arrays preserve order—lists of items, log lines, or coordinates.
• Strings carry text; numbers are IEEE 754 binary64 in most parsers (watch integers beyond 2^53 in JavaScript).
• Booleans and null are explicit so parsers do not guess.

Nesting and payload shape

Real APIs nest objects inside arrays and arrays inside objects: a search result might be { "items": [ { "id": 1, "name": "…" } ], "total": 42 }. Deep nesting is readable in small doses; flat structures with IDs often scale better for clients that patch individual fields. JSON does not care which style you pick—the contract is whatever your OpenAPI or README promises.

JSON is not JavaScript

JavaScript object literals allow single-quoted keys, unquoted keys when valid identifiers, trailing commas, undefined, functions, and Date objects. JSON allows none of that. Browsers historically exposed JSON.parse and JSON.stringify so applications could cross the boundary safely. Treating API responses with eval() was the anti-pattern JSON was meant to replace.

Why JSON displaced XML for many APIs

XML excels when you need mixed content, namespaces, schemas baked into enterprise workflows, or document markup. JSON excels when you need a thin wire format for structured records over HTTP. JSON payloads are usually smaller, parsers are simpler, and every mainstream language ships a JSON library. XML’s attributes-versus-elements debate becomes a non-issue when everything is nested objects.

JSON5, JSONC, and the strictness tax

Humans want comments and trailing commas in hand-edited config. JSON5 and JSONC (JSON with comments) add those affordances for source files. Production APIs, however, overwhelmingly stick to RFC 8259 strict JSON so every consumer agrees on failure modes. A trailing comma that your editor tolerates will break another team’s strict parser—that is why paste jobs into validators still fail in 2026.

Serialization and parsing

Serialization choices matter: default stringify may drop undefined properties in JavaScript, reorder object keys unpredictably, or serialize dates as ISO strings only if you add a replacer. API designers document those rules so clients do not rely on key order or implicit type coercion.

Validation and common errors

• Trailing commas after the last array element or object property
• Single-quoted strings instead of double quotes
• Unquoted keys (JavaScript habit pasted into JSON)
• JavaScript literals: undefined, NaN, Infinity
• Comments copied from config templates
• Mismatched brackets or stray commas between values
• Invalid Unicode escapes (\u must be four hex digits)

When integration fails, run the payload through a formatter and validator before blaming the server. Half of “the API returns bad JSON” reports are copy-paste damage or middleware double-encoding a string that was already JSON.

JSON in APIs and interchange

HTTP APIs commonly send JSON with Content-Type: application/json. Clients send Accept: application/json to prefer JSON responses. GraphQL and other styles still often serialize results as JSON over HTTP. CSV remains popular for spreadsheets; SmartKitio’s json-to-csv and csv-to-json tools exist for the handoff between flat tables and nested API shapes—not because one format is superior, but because teams live in both worlds.

Real limitations (not myths)

• No standard date type—use ISO 8601 strings and document time zones.
• No binary type—use Base64 in a string (with size cost) or separate binary endpoints.
• No schema enforced by the format itself—use JSON Schema, OpenAPI, or custom validators.
• No comments or metadata in strict JSON—use adjacent fields like "_comment" if you must (and document that convention).
• Duplicate keys in objects: RFC 8259 says names should be unique; parsers may disagree on which value wins—do not rely on duplicates.

Annotated JSON: valid shape vs common paste errors

The block below is valid strict JSON—note double-quoted keys, no comments, no trailing comma after the last property. Many “JSON” files in repos are actually JSON5 or JavaScript literals; pasting them into a strict validator fails for predictable reasons called out afterward.

{
  "data": {
    "id": "usr_8f2a",
    "email": "dev@example.com",
    "roles": ["reader", "editor"]
  },
  "meta": {
    "requestId": "req_91bc",
    "cached": false
  }
}

Wrapping resources in data plus meta is a recurring pattern: data holds the resource, meta holds pagination, tracing IDs, or rate-limit hints without polluting the domain object.

{
  // TODO: remove before prod
  "data": {
    "id": "usr_8f2a",
    "email": "dev@example.com",
    "roles": ["reader", "editor",],
  },
  "meta": { "requestId": "req_91bc", "cached": false }
}

SmartKitio’s JSON formatter and validator enforce the same strict rules production APIs expect—so you can prettify, minify, and catch syntax errors locally before a payload hits a staging server.