JSON

JSON was popularised by Douglas Crockford from around 2001 as a subset of JavaScript literal syntax. It was first described in RFC 4627 (2006), and today two aligned specifications define it: RFC 8259 (December 2017, Internet Standard STD 90) and ECMA-404 (2nd edition, 2017). The grammar is tiny: objects, arrays, strings, numbers and the literals true, false and null. Insignificant whitespace is limited to space, tab, line feed and carriage return; there are no comments, no trailing commas, no single-quoted strings and no NaN or Infinity. Control characters U+0000 to U+001F must be escaped in strings, and characters outside the Basic Multilingual Plane are written as \u escape surrogate pairs. The media type is application/json.

The interoperability gaps are deliberate and matter in practice. RFC 8259 §4 says member names SHOULD be unique but leaves duplicates undefined: JavaScript's JSON.parse keeps the last value, other parsers keep the first or reject the document. When a security filter and a back-end use different parsers, a duplicated key can mean one thing to the check and another to the consumer. Numbers have no precision limit in the grammar, but §6 notes that IEEE 754 binary64 is widely implemented, so integers outside the range -(2^53)+1 to (2^53)-1 lose precision in JavaScript; this is why APIs often ship large identifiers as strings. §8.1 requires UTF-8 for JSON exchanged between systems that are not part of a closed ecosystem. The I-JSON profile (RFC 7493) closes these gaps by forbidding duplicate names and constraining numbers and encoding.

Security issues come mostly from what happens after parsing. Early code evaluated JSON with eval(), which executed any embedded script. In JavaScript, merging parsed objects that contain a "__proto__" key can cause prototype pollution. Libraries that instantiate types named in the input, such as polymorphic typing in Jackson or TypeNameHandling in Json.NET, have produced remote-code-execution bugs classed as insecure deserialization (CWE-502). Deeply nested or huge input can exhaust stack or memory, so parsers need depth and size limits. For signatures, JOSE (JWS, RFC 7515; JWT, RFC 7519) signs the base64url-encoded bytes to avoid canonicalisation, while the JSON Canonicalization Scheme (RFC 8785) defines a canonical form where one is needed.

Around the core sits an ecosystem: JSON Schema (draft 2020-12, also used by OpenAPI 3.1) for validation, JSON Pointer (RFC 6901), JSON Patch (RFC 6902) and JSON Merge Patch (RFC 7396) for partial updates, and newline-delimited JSON for streaming. Compared with XML, JSON has no attributes, namespaces or entity expansion, so XXE-style attacks do not apply; YAML 1.2 is designed as a superset of JSON; and Protocol Buffers trade readability for a compact binary encoding with a mandatory schema.