What is JSON?

Six kinds of value

Every JSON value is one of six things: an object (key-value pairs in braces), an array (an ordered list in brackets), a string, a number, true/false, or null. They nest freely, and every complex structure is built from those pieces.

{
  "orderId": "SO-2026-1042",
  "customer": { "name": "Jane Doe", "business": false },
  "items": [
    { "sku": "COF-250", "qty": 2, "unitPrice": 12.5 },
    { "sku": "GRD-01", "qty": 1, "unitPrice": 89 }
  ],
  "deliveryNote": null,
  "createdAt": "2026-10-03T09:15:00+03:00"
}

RFC 8259 requires JSON exchanged between systems to be encoded as UTF-8, and its media type over HTTP is application/json.

What breaks a parser

Because JSON looks like a JavaScript object literal, most errors come from that resemblance. All of these are valid JavaScript and invalid JSON:

• Unquoted keys ({ name: "Jane" }) or single-quoted strings.
• A trailing comma after the last item ([1, 2, 3,]).
• Comments. Standard JSON has none; the commented variant some tools accept in config files (such as JSONC) is a separate extension.
• undefined, NaN, Infinity or functions.

Numbers, dates and duplicate keys

Large integers: the JSON grammar sets no limit on numbers, but many runtimes, JavaScript included, read them as 64-bit floating point, so integers above 2^53 lose precision. RFC 8259 recommends staying within that range for interoperability.

JSON.parse('{"id": 9007199254740993}').id
// 9007199254740992  (the last digit silently changed)

That is why many APIs send large database IDs and monetary amounts as strings.

Dates: JSON has no date type. The safest convention is an ISO 8601 string that includes the offset, like createdAt above. Local formats such as "10/03/2026" are ambiguous: October 3rd or March 10th?

Duplicate keys: if an object contains "price" twice, which one wins depends on the parser. Because that ambiguity can undermine validation and security checks, JSON you produce should never contain duplicate keys.

Parsing and serialising safely

const text = JSON.stringify({ name: "Jane", score: 4.5 });
// '{"name":"Jane","score":4.5}'

try {
  const data = JSON.parse(incomingText);
} catch (err) {
  // Invalid JSON: reject the request with a 400, don't crash the process
}

Never run untrusted text through eval; JSON.parse only produces data and never executes code. A successful parse still says nothing about shape, so validate the structure too. JSON Schema is the usual contract language for that, and REST API descriptions in OpenAPI build on the same idea.

JSON versus JSON-LD

JSON-LD is a W3C standard that uses JSON syntax and adds a layer of meaning. Special keys such as @context and @type declare which vocabulary a field like “name” comes from and what concept it represents. Every JSON-LD document is valid JSON, but an ordinary JSON object tells a search engine nothing. That is why Schema.org structured data on web pages is embedded as JSON-LD rather than plain JSON.

Plain JSON's home is moving data between applications: API requests and responses, webhook payloads, configuration files such as package.json, PostgreSQL jsonb columns, and document-oriented NoSQL databases.