RFC 4627 — First Official JSON RFC

JSON Before the RFC

JSON was informally described by Douglas Crockford in the early 2000s as a subset of JavaScript literal notation. Crockford registered the domain json.org in 2002 and published a simple grammar there. The format spread rapidly through the web development community because it was both human-readable and natively parseable by JavaScript — developers used eval() to parse it before JSON.parse existed.

State Object Notation predated the RFC. Flickr started using JSON in APIs around 2004; Yahoo's APIs supported it by 2005. By the time RFC 4627 was published in July 2006, JSON was already in widespread production use without a formal specification.

What RFC 4627 Defined

RFC 4627 formalised what Crockford had informally specified at json.org, with two main contributions:

• The grammar: A formal BNF-like specification of the JSON value types (object, array, string, number, boolean, null) and their syntax. The grammar in RFC 4627 is nearly identical to what all parsers implement today.
• The media type: Registration of application/json as the MIME type for JSON content, with parameters for character encoding indication.

The RFC also described JSON as a proper subset of JavaScript, though this description was later found to be slightly inaccurate (certain Unicode line separator characters are valid JSON strings but invalid in JavaScript string literals).

The application/json Media Type

Registering application/json as an IANA media type was arguably RFC 4627's most durable contribution. The media type is how servers and clients identify JSON content in HTTP messages:

Content-Type: application/json
Accept: application/json

Before the RFC, developers used text/javascript or ad-hoc types for JSON responses. The registered type standardised content negotiation and made it possible to write content-type-aware middleware and parsers.

The application/json media type registration has remained unchanged through RFC 7159 and RFC 8259 — the media type itself is one of the most stable parts of the JSON standard.

Known Limitations Fixed Later

RFC 4627 had two significant limitations that successor RFCs addressed:

• Top-level value restriction: RFC 4627 stated that a JSON text must be an object or array. Primitive values like strings and numbers at the top level were invalid. This was an arbitrary constraint not shared by JavaScript's JSON.parse or any practical parser. RFC 7159 (2014) lifted this restriction.
• Encoding ambiguity: RFC 4627 permitted UTF-8, UTF-16 BE, UTF-16 LE, UTF-32 BE, and UTF-32 LE, with a complex auto-detection algorithm based on the first four bytes. In practice, UTF-8 was universal but the spec allowed alternatives that caused interoperability issues. RFC 8259 (2017) mandated UTF-8 for interoperable JSON.