The JavaScript Object Notation (JSON) Data Interchange Format
obsoleted by
- rfc-7159 — The JavaScript Object Notation (JSON) Data Interchange Format
Extracted elements (25)
RFC 7158 expanded the definition of 'JSON text' from 'must be an object or array' to 'any JSON value'. This change was made because RFC 4627's constraint was inconsistent with ECMAScript's JSON specification and with widespread practice.
The errata removal of the security note 'A JSON text can be safely passed...' (RFC Errata 3607) reflected the realization that this guidance was incorrect and could encourage use of eval(), which is inherently unsafe regardless of structural properties of the JSON text.
The Unicode reference was changed to be non-version-specific, as future changes in the Unicode specification are not expected to impact JSON syntax. This avoids the need to update the RFC when Unicode versions advance.
RFC Errata ID 607 corrected misaligned artwork in the RFC 4627 definition of 'object'; RFC Errata ID 3607 removed the erroneous security note claiming a JSON text could be safely passed to JavaScript's eval(). Both errata from RFC 4627 are applied in this revision.
Good number interoperability can be achieved by implementations that expect no more precision or range than IEEE 754-2008 binary64 (double precision). Integers in the range [-(2**53)+1, (2**53)-1] are exactly interoperable; numbers like 1E400 or high-precision decimals indicate potential interoperability problems.
Implementations may set limits on text size, nesting depth, number range and precision, and string length. These limits are permitted but not specified by the grammar, and may affect interoperability.
Implementations that generate only objects or arrays (as RFC 4627 constrained) remain interoperable, since all conforming parsers will accept objects and arrays as valid JSON texts. The expanded definition is backward-compatible.
JSON parsing libraries differ as to whether they expose the ordering of object members to calling software. Implementations whose behavior does not depend on member ordering will be unaffected by these differences.
String comparison implementations should transform strings into sequences of Unicode code units and compare numerically, code unit by code unit. Comparing strings with escaped characters unconverted may incorrectly find that 'a\\b' and 'a\u005Cb' are unequal.
The ABNF allows member names and string values to contain bit sequences that cannot encode Unicode characters (e.g., unpaired UTF-16 surrogates like \uDEAD). Behavior of software receiving such values is unpredictable and may include fatal runtime exceptions.
A JSON generator produces JSON text, and the resulting text MUST strictly conform 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 value MUST be an object, array, number, or string, or one of the three literal names: false, null, true. The literal names MUST be lowercase; no other literal names are allowed.
Implementations MUST NOT add a byte order mark (BOM) to the beginning of a JSON text. Implementations that parse JSON texts MAY ignore a BOM rather than treating it as an error.
JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default encoding is UTF-8, which is interoperable in the sense that it will be read successfully by the maximum number of implementations.
Numeric values that cannot be represented in the JSON number grammar, such as Infinity and NaN, are not permitted.
The names within a JSON object SHOULD be unique. When names are not unique, behavior of receiving software is unpredictable — implementations variously report only the last pair, an error, or all pairs including duplicates.
A JSON array is square brackets surrounding zero or more comma-separated values. Values in an array are not required to be of the same type.
A JSON object is a pair of curly brackets surrounding zero or more name/value members. Each name is a string, followed by a colon separator, followed by a value; members are comma-separated. Object member ordering is not specified.
JSON supports six value types: object, array, number, string, and the three literal values true, false, and null. This revision expanded JSON text to allow any value, not only objects or arrays as RFC 4627 constrained.
The MIME media type 'application/json' is registered for JSON text. File extension is .json; no charset parameter is defined. The change controller is the IESG.
Using a language's eval() function (or equivalent) to parse JSON texts constitutes an unacceptable security risk, since the text could contain executable code along with data declarations. This applies to JavaScript and any other language in which JSON texts conform to that language's syntax.
A JSON number is represented in base 10 as '[ minus ] int [ frac ] [ exp ]'. Leading zeros are not allowed; Infinity and NaN are not permitted. The fraction part is a decimal point followed by one or more digits; the exponent part begins with 'e' or 'E' optionally followed by a sign.
A JSON string begins and ends with quotation marks (%x22). Control characters U+0000–U+001F, quotation mark, and reverse solidus must be escaped. Characters in the BMP may be escaped as \uXXXX (six characters); characters outside the BMP are encoded as a 12-character UTF-16 surrogate pair escape sequence.
A JSON text is defined as 'ws value ws'. The six structural characters are: begin-array (%x5B '['), begin-object (%x7B '{'), end-array (%x5D ']'), end-object (%x7D '}'), name-separator (%x3A ':'), and value-separator (%x2C ','). Insignificant whitespace (space, tab, line feed, carriage return) is allowed before or after any structural character.