JSON has no version number in the file. It has been specified several times, and the grammar has hardly changed: what changed is the top-level rule and the encodings allowed.
The specifications
| Document | Date | What it did |
|---|---|---|
| RFC 4627 | July 2006 | The first RFC, Informational. A text had to be an object or an array. UTF-8 was the default, and UTF-16 and UTF-32 were allowed. Registered application/json. |
| RFC 7158 | March 2013 | Standards Track; obsoleted RFC 4627. |
| ECMA-404, 1st edition | October 2013 | Ecma International’s definition of the syntax. |
| RFC 7159 | March 2014 | Standards Track; obsoleted RFC 4627 and RFC 7158. A text could be any value. UTF-8, UTF-16 and UTF-32 were allowed, with UTF-8 the default. |
| RFC 8259 | December 2017 | The current RFC, also STD 90. Requires UTF-8 outside a closed ecosystem, and makes ECMA-404 a normative reference. |
| ECMA-404, 2nd edition | December 2017 | The current edition of the syntax. |
ECMA-404 and the RFCs
ECMA-404 and RFC 8259 describe the same syntax. ECMA-404 defines only the syntax. The RFC adds rules about how software should treat it: the encoding, unique names, and the limits on numbers and surrogates.
What a file needs for each
| Text | RFC 4627 | RFC 7159 | RFC 8259 |
|---|---|---|---|
| An object or array at the top | Yes | Yes | Yes |
| A string, number or literal at the top | No | Yes | Yes |
| UTF-8 | Yes | Yes | Yes |
| UTF-16 or UTF-32 between systems | Yes | Yes | No |
Because the top-level rule was widened, a program written for RFC 4627 can refuse
42 or "text", which later specifications accept.