The JavaScript Object Notation (JSON) Data Interchange Format
Extracted elements (23)
ECMA-404 is cited as a normative reference not to require implementors to consult it for additional rules, but to emphasize that the definition of 'JSON text' is consistent between IETF and ECMA specifications. Where practices differ, this document recommends the more interoperable approach.
JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript. It was derived from ECMAScript object literal syntax, which explains its structural characters and string escape conventions.
UTF-8 is mandated for networked JSON (a change from RFC 7159) not because other encodings are technically invalid, but because the vast majority of JSON implementations already use UTF-8 and it is the only encoding that achieves practical interoperability.
RFC 8259 applies errata from RFC 4627 (Errata IDs 607 and 3607) and RFC 7159 (Errata IDs 3915, 4264, 4336, and 4388), removing inconsistencies and repairing specification errors from those predecessor documents.
A JSON text may be any JSON value, not just an object or array. Implementations that generate only objects or arrays will be accepted by all conforming parsers, maintaining backward compatibility with earlier specifications that restricted the top-level form.
JSON implementations differ on whether object member ordering is visible to calling software. Implementations whose behavior does not depend on member ordering are interoperable across all such implementations.
Numbers representable as IEEE 754 binary64 (double precision) integers in the range [-(2**53)+1, (2**53)-1] are interoperable — all implementations will agree exactly on their numeric values. Numbers outside this range or with extreme precision may cause interoperability problems.
String comparison implementations that convert escaped characters to Unicode code units before numeric comparison are interoperable. Implementations that compare escaped and unescaped forms without normalization may incorrectly find `"a\\b"` and `"a\u005Cb"` unequal.
Unpaired UTF-16 surrogates (e.g., `\uDEAD`) are syntactically allowed by the ABNF but lead to unpredictable behavior — implementations may return different string lengths or suffer fatal exceptions. JSON texts containing only valid Unicode characters are interoperable.
A JSON generator MUST produce text that strictly conforms to the JSON grammar.
A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions.
A JSON text MUST be encoded using UTF-8 when exchanged between systems that are not part of a closed ecosystem. Previous specifications did not require UTF-8, but it is the only encoding that achieves interoperability in practice.
A JSON value MUST be an object, array, number, string, or one of the three literal names: false, null, true. The literal names MUST be lowercase.
Implementations MUST NOT add a byte order mark (U+FEFF) to the beginning of a network-transmitted JSON text. Parsers MAY ignore a BOM rather than treating it as an error.
The names within a JSON object SHOULD be unique. When names are not unique, behavior of receiving software is unpredictable — implementations vary between reporting last value, reporting error, or reporting all pairs.
An array is `begin-array [ value *( value-separator value ) ] end-array`. There is no requirement that values in an array be of the same type.
An object is `begin-object [ member *( value-separator member ) ] end-object` where `member = string name-separator value`. A name is always a string.
JSON defines six value types: object (unordered name/value pairs in curly brackets), array (ordered values in square brackets), number, string, and the three literal names true, false, and null.
The media type `application/json` is registered with IANA for JSON text. File extension is `.json`, Macintosh file type code is `TEXT`, no charset parameter is defined, and no required or optional parameters exist. Change controller is IESG.
Using JavaScript's `eval()` function (or equivalent in other languages) to parse JSON texts is an unacceptable security risk because the text could contain executable code alongside data. JSON is a subset of JavaScript that excludes assignment and invocation, but certain characters (U+2028, U+2029) legal in JSON are not legal in JavaScript, making eval() unreliable as well as dangerous.
A JSON text is defined by the grammar `JSON-text = ws value ws`. The six structural characters are: begin-array `[` (%x5B), end-array `]` (%x5D), begin-object `{` (%x7B), end-object `}` (%x7D), name-separator `:` (%x3A), and value-separator `,` (%x2C), each optionally surrounded by insignificant whitespace (space, tab, LF, CR).
JSON numbers are base-10, optionally prefixed with a minus sign, with optional fraction (decimal point followed by digits) and optional exponent (E/e, optional sign, digits). Leading zeros are not allowed. Infinity and NaN are not permitted.
JSON strings begin and end with quotation marks (`"`). Characters that MUST be escaped are: quotation mark, reverse solidus, and control characters U+0000 through U+001F. BMP characters may be escaped as `\uXXXX`; non-BMP characters require a 12-character UTF-16 surrogate pair escape sequence.