What RFC 7159 Changed
RFC 7159 was published in March 2014 by Tim Bray, superseding Douglas Crockford's RFC 4627 from 2006. The motivation was primarily to address known technical limitations in the original specification — not to change the JSON format, but to clarify and extend the normative text that described it.
The RFC also transferred the document from Crockford (as an individual author) to the IETF's JSON working group, reflecting JSON's transition from a personal project to an industry-wide standard that needed formal institutional stewardship.
The Top-Level Value Relaxation
The most significant user-visible change in RFC 7159 was the removal of the restriction on top-level JSON values. RFC 4627 stated that a JSON text must be a serialised object or array:
// RFC 4627: this was the only valid "JSON text"
{"key": "value"}
[1, 2, 3]Primitive values like strings, numbers, booleans, and null were not valid stand-alone JSON texts under RFC 4627. This created awkward situations: JSON.parse("true") worked in every JavaScript engine, but the result wasn't technically a "JSON text" per the specification.
RFC 7159 corrected this by defining a JSON text as "a serialized value" — any JSON value at all. "hello", 42, and true became valid JSON texts. This aligned the specification with what all parsers already implemented.
Encoding Ambiguities Remain
RFC 7159 retained RFC 4627's encoding flexibility: JSON could still be encoded in UTF-8, UTF-16, or UTF-32. The RFC suggested UTF-8 as the preferred encoding but did not mandate it. This left the door open for the interoperability problems that UTF-16 and UTF-32 JSON caused in practice (content negotiation failures, BOM handling issues, parser incompatibilities).
The encoding question was finally resolved in RFC 8259, which made UTF-8 mandatory for interoperable JSON. RFC 7159 is therefore a stepping stone — it fixed the top-level restriction and improved the specification text, but left the encoding problem for the next revision.
The Path to RFC 8259
RFC 7159 was published in March 2014 and obsoleted by RFC 8259 in December 2017 — a lifespan of less than four years. The relatively quick succession was driven by the ECMA-404 coordination process: when Ecma published ECMA-404 in 2013 and then worked toward its second edition, the IETF updated the RFC track to stay aligned.
RFC 7159 is now of historical interest only. No implementation should target it; RFC 8259 supersedes it in all respects.