Developer tools · JSON formatter & validator
JSON's standards history: RFC 4627 to RFC 8259 and ECMA-404
· Background
json standards validation
JSON has been specified at least four times by two standards bodies. This post traces the path from Douglas Crockford's json.org to RFC 8259 and ECMA-404, and explains what actually changed for developers along the way.
Which spec is my parser following?
Which specification is a parser following? The answer is usually visible at the edges rather than in ordinary objects and arrays. Test a top-level string such as `"ready"`, a leading byte-order mark, duplicate member names and unusually large numbers. Different documents discuss syntax and interoperability at different levels, while implementations add their own data types and error behavior. Naming a standard is useful only when the observed parser contract is kept separate from assumptions about every JSON implementation.
The repository evidence for ToolAcre is concrete and narrower than a general standards history. The formatter uses `JSON.parse` to produce values and `JSON.stringify` to emit them; after a parse failure, a local scanner supplies a stable diagnostic position and reason.
json.org and the early description of JSON
json.org presented JSON as a compact notation derived from JavaScript’s object-literal syntax and documented its core structures with a small grammar. That early description helped give developers a shared name and reference for objects, arrays, strings, numbers, booleans and null. It is safer to describe the page as an early public explanation than to claim, without cited historical evidence here, that one page or person single-handedly discovered a format or established its adoption.
The current repository sources do not include an archival history of json.org, browser usage or committee discussions. They show how this application parses and diagnoses JSON today. Accordingly, historical statements in this article stay close to dated standards documents and avoid attributing motives or market effects that those local files cannot prove.
RFC 4627 in 2006 — the first IETF description, the application/json media type and the rule that a text had to be an object or array
RFC 4627, published in 2006, described JSON for Internet interchange and registered the `application/json` media type. Its definition of a JSON text required an object or array at the top level, even though strings, numbers and literals existed as values inside those containers. That restriction is a useful historical difference because a document containing only `"ready"` could be a valid value in a later formulation while falling outside RFC 4627’s JSON-text definition.
The document also discussed encoding and security concerns in the context of implementations available at the time. It should not be read as a changelog for this repository: ToolAcre does not contain an RFC 4627 compatibility mode, and its parser path delegates value construction to the host JavaScript engine.
ECMA-404 in 2013 — Ecma's minimal syntax-only standard, and why two organisations ended up describing one format
ECMA-404, first published in 2013, specifies JSON syntax in a deliberately compact form. Its focus is the grammar of valid JSON text rather than a complete interchange profile for every networked use. That scope helps explain why ECMA-404 and the IETF documents can describe the same basic notation while differing in the surrounding interoperability guidance they emphasize. The existence of two standards bodies does not imply two incompatible formats in ordinary use.
Claims about why organizations chose particular publication paths require documentary sources beyond this codebase, so this article does not infer committee motives from the standards’ dates. The relevant practical point is that RFC 8259 and ECMA-404 are intended to align on syntax, while RFC 8259 supplies recommendations that matter to interoperable exchange.
RFC 7159 and RFC 8259
RFC 7159 replaced RFC 4627 in 2014 and broadened the definition of a JSON text to any serialized value, removing the object-or-array-only top-level rule. RFC 8259 replaced RFC 7159 in 2017 and remains the IETF reference normally cited for JSON. It requires UTF-8 for JSON exchanged between systems outside a closed ecosystem and records interoperability cautions around numbers, duplicate names, Unicode and byte-order marks rather than pretending grammar alone guarantees identical results everywhere.
A top-level `true` is a compact way to observe the modern root-value rule in ToolAcre because `JSON.parse` accepts it. That result demonstrates this implementation’s behavior; it does not reconstruct when every browser, server or API adopted the broader definition.
What changed for working developers
For working developers, the clearest specification changes are the modern acceptance of any JSON value at the root and stronger guidance for interoperable encoding. The less visible lesson is that valid syntax still leaves implementation choices. Duplicate object names may be collapsed, member ordering is not a semantic contract, very large numbers may lose precision, and unusual Unicode sequences can travel differently through libraries. A standards-compliant document can therefore deserve additional constraints from an application schema.
In this formatter, duplicate names and number tokens first pass through `JSON.parse`, so later formatting reflects the resulting JavaScript value rather than the original lexical document. The scanner contributes diagnostics after failure; it does not preserve duplicate members or arbitrary-precision numbers. Those are repository-backed observations.
What this does not cover
What this does not cover are the specifications layered on top of JSON. JSON Schema describes constraints on document shape and values; JSON Pointer addresses locations within a document; JSON Patch represents changes. They solve different problems from the base grammar and should not be treated as later versions of JSON itself. JSONC, JSON5 and similar authoring formats also extend or alter accepted syntax and require their own parsers rather than being folded into strict validation silently.
This article also avoids a comprehensive social history of JSON adoption, browser support or competition with XML because the listed repository sources cannot substantiate that narrative. No external citations have been invented to fill the gap.
Takeaway: RFC 8259 is the reference to cite
RFC 8259 is the practical IETF reference to cite for current JSON syntax and interoperability guidance, with ECMA-404 providing the aligned Ecma syntax standard. RFC 4627 and RFC 7159 remain useful for understanding how the published definition changed, especially at the top level. Cite the document that supports the exact claim instead of using “the JSON spec” as a vague appeal to authority, and distinguish normative rules from implementation behavior observed in a particular parser.
For ToolAcre, the defensible statement is that the repository uses JavaScript’s JSON parser and serializer and adds a strict local scanner for diagnostics after failures. Tests of top-level values, malformed punctuation and number handling describe that route; they are not historical sources.