The JavaScript Object Notation (JSON) Data Interchange Format
Extracted elements (255)
JSON is a proper subset of JavaScript but deliberately excludes assignment and invocation, which reduces but does not eliminate security risks relative to arbitrary JavaScript execution. The security problem with `eval()` stems from JSON's syntactic compatibility with JavaScript, not from JSON itself.
JSON is defined as a subset of JavaScript that excludes assignment and invocation, limiting its attack surface compared to full JavaScript evaluation. Its design goals were to be minimal, portable, textual, and a subset of JavaScript.
JSON is intentionally minimal: it represents only four primitive types and two structured types, derived from JavaScript object literals, with the explicit design goals of being minimal, portable, textual, and a subset of JavaScript.
JSON object member ordering is deliberately left unspecified. JSON parsing libraries differ on whether they expose member ordering to callers; implementations that do not depend on member ordering are interoperable across all such implementations.
JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript. It was derived from ECMAScript object literals, which explains its syntax choices for structural characters and literal names.
JSON's design goals were minimality, portability, textual representation, and being a subset of JavaScript. The object and array terminology comes directly from JavaScript conventions, reflecting its origin in ECMAScript object literals.
JSON's design goals were to be minimal, portable, textual, and a subset of JavaScript. Its syntax is borrowed from JavaScript object literals but excludes assignment and invocation, making it safe for data-only interchange.
JSON text was redefined from RFC 4627's constraint (object or array only) to allow any JSON value, because implementations that generate only objects or arrays remain interoperable with all compliant parsers, while the looser definition enables simpler use cases.
JSON text was redefined to allow any JSON value (not just objects or arrays) to align with other JSON specifications (ECMAScript 5.1, ECMA-404) and to remove an inconsistency that had caused interoperability problems in practice.
No charset parameter is defined for the application/json media type registration because adding one has no effect on compliant recipients; the encoding is determined by the UTF BOM or statistical analysis, not a media type parameter.
No 'charset' parameter is defined in the application/json media type registration because JSON's encoding is fully determined by the UTF-8/16/32 detection rules in the specification; adding a charset parameter has no effect on compliant recipients.
Number interoperability is tied to IEEE 754-2008 binary64 (double precision): integers in the range [-(2**53)+1, (2**53)-1] are exactly interoperable. Numbers with greater magnitude or precision than binary64 can represent may indicate interoperability problems.
Number precision is deliberately unspecified to allow implementations to set their own limits; however, IEEE 754-2008 binary64 is highlighted as the de facto interoperability baseline because it is widely available, not because the spec mandates it.
RFC 4627 restricted a JSON text to be an object or array; RFC 7159 lifts this restriction so any JSON value (including bare strings, numbers, and literals) is a valid JSON text. This aligns with ECMAScript 5.1 and ECMA-404 and reflects actual implementation practice.
RFC 7159 broadened the definition of a valid JSON text to allow any JSON value (not just objects or arrays as RFC 4627 required), because implementations generating only objects or arrays remain interoperable with all conforming implementations, while the restriction served no practical purpose.
RFC 7159 changed the definition of 'JSON text' from RFC 4627 to allow any JSON value (not just object or array) as a top-level construct, enabling bare strings, numbers, and literals as valid JSON texts. This reflects widespread real-world usage.
RFC 7159 changes the definition of 'JSON text' from RFC 4627's constraint (object or array only) to allow any JSON value, including primitives. This reflects observed practice and improves consistency with ECMAScript and ECMA-404 specifications.
RFC 7159 expanded the definition of a JSON text to allow any JSON value (not just objects or arrays) as the top-level element. This reflects widespread implementation practice and real-world usage where single strings, numbers, or booleans are exchanged as JSON texts.
RFC 7159 expands the definition of a JSON text to be any JSON value, removing the RFC 4627 constraint that required a JSON text to be an object or an array. This change reflects real-world usage and allows values such as strings, numbers, and booleans to stand alone as valid JSON texts.
RFC 7159 expands the definition of 'JSON text' to allow any JSON value (not just objects or arrays, as RFC 4627 required). This reflects observed practice and acknowledges that implementations generating only objects or arrays remain interoperable with all conforming receivers.
RFC 7159 generalizes the definition of a JSON text from 'must be an object or array' (RFC 4627) to 'any JSON value'. This change reflects real-world usage and removes an inconsistency with other JSON specifications, while noting that generators producing only objects or arrays remain interoperable.
RFC 7159 relaxes RFC 4627's constraint that a JSON text must be an object or array, allowing any JSON value as a top-level JSON text. The rationale is that implementations generating only objects or arrays remain interoperable, while the restriction was unnecessarily narrow given how JSON is used in practice.
RFC 7159 relaxes the RFC 4627 constraint that a JSON text must be an object or array, allowing any JSON value as a top-level text, because this removes an inconsistency with ECMAScript and other JSON specifications and reflects actual widespread practice.
RFC 7159 removes the RFC 4627 constraint that a JSON text must be an object or array, allowing any JSON value as a top-level text. This reflects observed practice and improves consistency with ECMAScript and ECMA-404 specifications of JSON.
The constraint that a JSON text must be an object or array (from RFC 4627) was removed because it conflicted with other JSON specifications and real-world practice; any JSON value is now a valid JSON text, though object- and array-only generators remain interoperable.
The ECMAScript reference was moved from normative to informative because JSON's design goals (minimal, portable, textual, JavaScript subset) are captured entirely in the ABNF grammar, and the spec should not be tied to a specific ECMAScript edition.
The no-BOM requirement exists because UTF-8 encoding of JSON does not require a BOM to determine encoding, and adding one reduces interoperability with implementations that cannot handle it.
The reference to the Unicode Standard is intentionally non-version-specific, because future Unicode changes are not expected to impact JSON syntax. This avoids mandatory document updates whenever Unicode releases a new version.
The specification recommends UTF-8 as the default encoding because it is the most widely supported; UTF-16 and UTF-32 are permitted but many implementations cannot read them, making UTF-8 the pragmatic choice for interoperability.
The Unicode reference in JSON is intentionally not version-specific; future changes to the Unicode specification are not expected to impact JSON syntax, so citing the latest version rather than a pinned release was chosen deliberately.
The Unicode reference in the specification is intentionally not version-specific, citing the latest version of Unicode rather than a fixed release. Future changes in the Unicode specification are not expected to impact JSON syntax.
The Unicode reference in this document intentionally cites the latest version rather than a specific release, because future changes in the Unicode specification are not expected to impact JSON's syntax.
The Unicode reference in this revision is not version-specific (referencing the latest version rather than a fixed release) because future changes in the Unicode specification are not expected to impact JSON's syntax.
The Unicode reference is deliberately not version-specific, citing the latest version. Future changes to the Unicode specification are not expected to impact JSON syntax.
The Unicode reference is intentionally non-version-specific (citing the latest version rather than a fixed release), because future Unicode changes are not expected to impact JSON syntax. This was a deliberate change from RFC 4627.
The UNICODE reference is intentionally not pinned to a specific release because future Unicode changes are not expected to impact JSON syntax. This avoids the specification becoming outdated as new Unicode versions are published.
The Unicode reference is intentionally not version-specific, citing the latest version rather than a fixed release, because future Unicode changes are not expected to impact JSON's syntax.
The Unicode reference was changed from a version-specific citation to the latest version, as future Unicode changes are not expected to impact JSON syntax and pinning to a specific version was unnecessarily restrictive.
The Unicode reference was intentionally made non-version-specific (citing the latest version rather than a fixed release) because future Unicode changes are not expected to impact JSON syntax.
UTF-8 is the default and recommended encoding because it is interoperable with the maximum number of implementations; many implementations cannot successfully read UTF-16 or UTF-32 encoded JSON texts.
RFC 4627 Errata IDs 607 and 3607 are applied in this revision. Erratum 607 corrected artwork alignment in the object definition; erratum 3607 removed a flawed security claim (the assertion that JSON text could be safely passed to JavaScript's `eval()`) along with its associated JavaScript code example.
RFC 7159 applies RFC 4627 Errata IDs 607 and 3607: erratum 607 corrects the artwork for the object grammar definition; erratum 3607 removes an unsafe security guidance passage that suggested JSON could be safely passed to JavaScript's eval() function.
RFC 7159 applies RFC 4627 erratum #607 (correcting artwork alignment for the 'object' definition) and erratum #3607 (removing a security consideration that claimed JSON could be safely passed to JavaScript's eval() and associated JavaScript code, which was incorrect).
RFC 7159 applies two errata from RFC 4627: Errata ID 607 (correct artwork alignment for the object grammar definition) and Errata ID 3607 (removal of an incorrect security consideration claiming JSON could be safely passed to JavaScript's eval()).
RFC Errata ID 3607 (applied from RFC 4627) removed the security consideration that began 'A JSON text can be safely passed' along with associated JavaScript eval() code, which was incorrect guidance.
RFC Errata ID 3607 removed from RFC 4627 a security consideration that incorrectly claimed a JSON text could be safely passed to a JavaScript `eval()` call, along with the supporting JavaScript code.
RFC Errata ID 607 (alignment of object artwork) and Errata ID 3607 (removal of the flawed 'JSON text can be safely passed' security claim and associated JavaScript eval example) from RFC 4627 were applied in this revision.
RFC Errata ID 607 (applied from RFC 4627) corrected the artwork alignment for the ABNF definition of 'object'. RFC Errata ID 3607 removed an erroneous security consideration that claimed JSON could be safely passed to JavaScript's eval(), along with accompanying JavaScript code.
RFC Errata ID 607 corrected misaligned artwork for the ABNF definition of 'object' in RFC 4627; this was applied in RFC 7159. Errata ID 3607 removed a flawed security claim that JSON could be safely passed to JavaScript's eval(), which was incorrect.
RFC Errata ID 607 corrected the artwork alignment for the ABNF definition of `object` in RFC 4627.
RFC Errata ID 607 corrected the artwork for the ABNF definition of 'object' in RFC 4627; this was applied in RFC 7159.
RFC Errata ID 607 (from RFC 4627) corrected the alignment of the artwork for the 'object' definition. RFC Errata ID 3607 caused removal of the security consideration that began 'A JSON text can be safely passed' along with the associated JavaScript code.
RFC Errata ID 607 (misaligned artwork for the object definition) and Errata ID 3607 (removal of an incorrect security consideration claiming JSON could be safely passed to eval()) from RFC 4627 were applied in this revision.
RFC Errata ID 607 (RFC 4627) corrected artwork alignment for the 'object' definition. RFC Errata ID 3607 removed a security consideration claiming JSON could be 'safely passed' to JavaScript's eval(), along with accompanying JavaScript code.
This document applies RFC 4627 Errata ID 607 (correcting artwork alignment for the object definition) and Errata ID 3607 (removing an incorrect security consideration that claimed JSON texts could be safely passed to JavaScript's eval()).
This document applies RFC Errata ID 607 (correcting artwork alignment in the object definition) and Errata ID 3607 (removing the security consideration claiming JSON text can be safely passed to JavaScript's eval(), which was found to be incorrect).
This document applies RFC Errata IDs 607 and 3607 from RFC 4627. Erratum 607 corrected artwork alignment for the object definition; erratum 3607 removed an incorrect security consideration claiming JSON could be safely passed to JavaScript's eval() along with associated JavaScript code.
Duplicate object member names cause unpredictable behavior across implementations—some report only the last pair, others report an error, and some report all pairs including duplicates. Software should not rely on any particular behavior.
For good interoperability, implementations should expect no more numeric precision or range than IEEE 754-2008 binary64 (double precision). Integers in the range [-(2**53)+1, (2**53)-1] are exactly interoperable across implementations.
For numeric interoperability, implementations should 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 representable and interoperable across all conforming implementations.
Good interoperability can be achieved by implementations that expect no more numeric precision or range than IEEE 754-2008 binary64 (double precision). Integers in the range [-(2**53)+1, (2**53)-1] are interoperable; numbers outside this range or with extreme precision (e.g., 1E400) may cause interoperability problems.
Good interoperability is 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 outside this range or with excessive precision may cause interoperability problems.
Implementations generating only objects or arrays where a JSON text is called for will be interoperable, since all implementations accept these as conforming JSON texts, even though RFC 7159 now allows any JSON value as a top-level text.
Implementations should expect no more numeric precision or range than IEEE 754-2008 binary64 (double precision). Integers in the range [-(2**53)+1, (2**53)-1] are interoperable; numbers outside this range or with extreme precision (e.g., 1E400) indicate potential interoperability problems.
Implementations should 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 outside this range (e.g., 1E400) indicate potential interoperability problems.
Implementations should normalize escape sequences before string comparison; comparing strings with escaped characters unconverted may incorrectly find `"a\\b"` and `"a\u005Cb"` unequal. Comparison should be done numerically, code unit by code unit.
Implementations that compare object member names by converting escape sequences to Unicode code units and comparing numerically (code unit by code unit) are interoperable. Implementations that compare escaped characters unconverted may incorrectly find that `"a\\b"` and `"a\u005Cb"` are not equal.
Implementations that compare strings by first converting escape sequences to Unicode code units and then comparing numerically are interoperable. Comparing escaped and unescaped representations without normalization may incorrectly treat equal strings as unequal (e.g., 'a\\b' vs 'a\u005Cb').
Implementations that compare strings by first converting to Unicode code unit sequences and performing numeric code-unit-by-code-unit comparison are interoperable; implementations that compare escaped and unescaped representations directly may incorrectly find strings unequal (e.g., "a\\b" vs "a\u005Cb").
Implementations that compare strings by transforming them to Unicode code unit sequences and comparing numerically are interoperable. Implementations that compare strings with escaped characters unconverted may incorrectly find that 'a\\b' and 'a\u005Cb' are not equal.
Implementations that expect no more numeric precision or range than IEEE 754-2008 binary64 (double precision) achieve good interoperability. Integers in the range [-(2**53)+1, (2**53)-1] are interoperable in that all implementations will agree exactly on their values.
Implementations that generate only JSON objects or arrays (as required by RFC 4627) remain interoperable with RFC 7159 parsers, which MUST accept any JSON value as a top-level text.
Implementations that generate only objects or arrays (as RFC 4627 required) remain interoperable with RFC 7159 implementations, since all RFC 7159 implementations accept objects and arrays as valid JSON texts.
Implementations that generate only objects or arrays at the top level remain interoperable because all conforming implementations will accept objects and arrays as valid JSON texts, even though any value is now permitted at the top level.
Implementations that generate only objects or arrays where a JSON text is called for will be interoperable in the sense that all implementations will accept these as conforming JSON texts, even though RFC 7159 now permits any value as a JSON text.
Implementations that normalize strings to sequences of Unicode code units before comparing numerically, code unit by code unit, are interoperable. Comparing strings with escaped characters unconverted may cause incorrect inequality results (e.g., treating "a\\b" and "a\u005Cb" as different).
Implementations that transform string representations into sequences of Unicode code units and compare numerically (code unit by code unit) are interoperable. Comparing strings with escaped characters unconverted may incorrectly find that 'a\\b' and 'a\u005Cb' are not equal.
Implementations that use IEEE 754-2008 binary64 (double precision) provide good interoperability for numbers within that range and precision. Integers in the range [-(2**53)+1, (2**53)-1] are exactly interoperable; numbers outside this range or with extreme precision may cause interoperability problems.
Implementations using IEEE 754-2008 binary64 (double precision) achieve good interoperability for numbers within that range and precision. Integer values in the range [-(2**53)+1, (2**53)-1] are exactly interoperable. Numbers like 1E400 or high-precision decimals indicate potential interoperability problems.
Integer values in the range [-(2^53)+1, (2^53)-1] are interoperable across implementations using IEEE 754-2008 binary64 (double precision). Numbers with greater magnitude or precision (e.g., 1E400) may not be representable and indicate potential interoperability problems.
Integers in the range [-(2^53)+1, (2^53)-1] are interoperable across implementations using IEEE 754-2008 binary64 (double precision). Numbers outside this range or with excessive precision may cause interoperability problems.
JSON object member ordering is not specified, and parsing libraries differ on whether ordering is visible to callers. Implementations whose behavior does not depend on member ordering are broadly interoperable.
JSON object member ordering visibility varies across parser implementations; software whose behavior does not depend on member ordering will be interoperable across all conforming implementations.
JSON parsers differ on whether object member ordering is visible to calling software. Implementations that do not depend on member ordering will be unaffected by these differences.
JSON parsers may set implementation-defined limits on text size, nesting depth, number range/precision, and string length/content. These limits are not specified by the standard, creating potential interoperability constraints.
JSON parsing libraries differ as to whether they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable.
JSON parsing libraries differ in whether they expose the ordering of object members to calling software. Implementations whose behavior does not depend on member ordering will be interoperable across these differences.
JSON parsing libraries differ on whether member ordering within objects is visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable across this difference.
JSON parsing libraries differ on whether object member ordering is visible to calling software. Implementations whose behavior does not depend on member ordering are more broadly interoperable.
JSON parsing libraries differ on whether they expose object member ordering to calling software. Implementations whose behavior does not depend on member ordering will be interoperable regardless of these differences.
JSON parsing libraries differ on whether they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable.
JSON strings containing unpaired UTF-16 surrogates (e.g., '\uDEAD') are syntactically allowed by the ABNF but produce unpredictable behavior across implementations, including differing string length results or fatal runtime exceptions.
JSON strings may legally contain bit sequences that do not encode valid Unicode characters (e.g., a single unpaired UTF-16 surrogate such as \uDEAD). Software receiving such values behaves unpredictably, including returning wrong string lengths or suffering fatal runtime exceptions.
JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. UTF-8 is the default and most interoperable encoding; many implementations cannot read UTF-16 or UTF-32.
JSON texts containing unpaired UTF-16 surrogates (e.g., `"\uDEAD"`) have unpredictable behavior across implementations — some return wrong string lengths, others throw fatal runtime exceptions.
Member names and string values may contain bit sequences that cannot encode valid Unicode characters (e.g., unpaired UTF-16 surrogates such as '\uDEAD'). The behavior of software receiving such values is unpredictable and may cause fatal runtime exceptions.
Numbers in the range [-(2**53)+1, (2**53)-1] that are integers are interoperable across implementations using IEEE 754-2008 binary64 (double precision). Numbers outside this range or with extreme precision (e.g., 1E400) may cause interoperability problems.
Numbers interoperate best within the IEEE 754-2008 binary64 (double precision) range. Integers in the range [-(2**53)+1, (2**53)-1] are exactly interoperable; numbers outside this range or with excess precision (e.g., 1E400) may cause interoperability problems.
Numbers representable as IEEE 754-2008 binary64 (double precision) in the integer range [-(2**53)+1, (2**53)-1] are interoperable across implementations. Numbers outside this range or with extreme precision (e.g., 1E400) may cause interoperability problems.
Numbers such as 1E400 or high-precision values like 3.141592653589793238462643383279 may indicate interoperability problems, since they imply the producer expects greater numeric range or precision than is widely available in IEEE 754 double-precision implementations.
Numbers that are integers in the range [-(2**53)+1, (2**53)-1] are interoperable across implementations using IEEE 754-2008 binary64 (double precision). Numbers outside this range or with extreme precision (e.g., 1E400) may cause interoperability problems.
Object member ordering is not defined; implementations differ in whether they expose ordering to calling software. Code that depends on member ordering will not be interoperable.
Object member ordering is not guaranteed; JSON parsing libraries differ as to whether they expose member ordering to calling software. Implementations should not depend on member ordering.
Object member ordering is not specified; implementations differ in whether they expose ordering to calling software. Software whose behavior does not depend on member ordering will be more interoperable.
Parsers may set implementation-defined limits on text size, nesting depth, number range and precision, and string length and character contents. These limits are not specified by the standard.
RFC 7159 expands the definition of a JSON text to allow any JSON value (not just objects or arrays as required by RFC 4627). Implementations generating only objects or arrays will remain interoperable with all conforming implementations.
RFC 7159 removes the RFC 4627 constraint that a JSON text must be an object or array; any JSON value is now a valid top-level JSON text. Implementations generating only objects or arrays remain interoperable since all implementations accept them.
String comparison implementations should convert textual representations to Unicode code unit sequences and compare numerically, code unit by code unit. Implementations that compare strings with escaped characters unconverted may incorrectly find that 'a\\b' and 'a\u005Cb' are not equal.
String comparison implementations should decode escape sequences before comparing, so that 'a\\b' and 'a\u005Cb' are recognized as equal. Implementations that compare without decoding may incorrectly report inequality.
String comparison implementations SHOULD transform strings into sequences of Unicode code units and compare numerically, code unit by code unit. Implementations that compare escaped characters without first unescaping them may incorrectly find that 'a\\b' and 'a\u005Cb' are not equal.
String comparison implementations SHOULD transform textual representations into Unicode code unit sequences and compare numerically, code unit by code unit. Comparing strings with escaped characters unconverted may incorrectly find unequal strings that are semantically equal.
String comparison implementations that convert escaped characters to Unicode code units before comparing numerically are interoperable. Implementations that compare strings with escaped characters unconverted may incorrectly find that 'a\\b' and 'a\u005Cb' are not equal.
String comparison implementations that convert textual representations to Unicode code-unit sequences and compare numerically are interoperable. Implementations that compare escaped and unescaped forms without normalizing them first may incorrectly find "a\\b" and "a\u005Cb" unequal.
String comparison implementations that convert to Unicode code unit sequences and compare numerically are interoperable; implementations that compare escaped characters without decoding may incorrectly find 'a\\b' and 'a\u005Cb' unequal.
String comparison implementations that first decode escape sequences to Unicode code units and then compare numerically are interoperable. Implementations comparing strings with escaped characters unconverted may incorrectly find that `a\\b` and `a\u005Cb` are not equal.
String comparison implementations that first transform textual representations into Unicode code unit sequences and compare numerically (code unit by code unit) are interoperable. Implementations that compare escaped characters unconverted may incorrectly find that 'a\\b' and 'a\u005Cb' are unequal.
String comparison implementations that transform text into Unicode code unit sequences and compare numerically are interoperable. Implementations that compare strings with escaped characters unconverted may incorrectly find that 'a\\b' and 'a\u005Cb' are not equal.
String comparison implementations that transform textual representations into sequences of Unicode code units and compare numerically code-unit-by-code-unit are interoperable. Implementations comparing strings with escaped characters unconverted may incorrectly treat '\\' and '\u005C' as unequal.
String comparison is interoperable only when implementations first decode escaped characters into Unicode code units and then compare numerically, code unit by code unit. Comparing strings with unconverted escape sequences may incorrectly treat `"a\\b"` and `"a\u005Cb"` as unequal.
String comparison must transform textual representation into Unicode code unit sequences and compare numerically, code unit by code unit, to ensure interoperability. Comparing escaped characters without unescaping may yield incorrect inequality results.
String comparison SHOULD be performed by converting to Unicode code unit sequences and comparing numerically. Implementations that compare escaped and unescaped forms without normalization may incorrectly find 'a\\b' and 'a\u005Cb' unequal.
The ABNF allows member names and string values containing bit sequences that cannot encode valid Unicode characters, such as unpaired UTF-16 surrogates (e.g., '\uDEAD'). Software receiving such values behaves unpredictably and may suffer fatal runtime exceptions.
The ABNF grammar allows member names and string values to contain bit sequences that cannot encode valid Unicode characters, such as unpaired UTF-16 surrogates (e.g., '\uDEAD'). Software receiving such values behaves unpredictably and may suffer fatal runtime exceptions.
The ABNF grammar permits member names and string values to contain bit sequences that do not encode valid Unicode characters, such as unpaired UTF-16 surrogates (e.g., `\uDEAD`). Software receiving such values may behave unpredictably, including returning wrong string lengths or throwing fatal exceptions.
The ABNF permits member names and string values to contain bit sequences that cannot encode Unicode characters, such as unpaired UTF-16 surrogates (e.g., `\uDEAD`). Receiving software behavior is unpredictable and may include incorrect string length results or fatal runtime exceptions.
The JSON ABNF allows string values to contain bit sequences that do not encode valid Unicode characters, such as a single unpaired UTF-16 surrogate (e.g., '\uDEAD'). Software receiving such values behaves unpredictably — implementations may return different string lengths or raise fatal exceptions.
The JSON ABNF permits member names and string values to contain bit sequences that cannot encode valid Unicode characters, such as unpaired UTF-16 surrogates (e.g., "\uDEAD"). Software receiving such values behaves unpredictably and may return wrong string lengths or suffer fatal runtime exceptions.
This document removes the RFC 4627 constraint that a JSON text must be an object or array; a JSON text may now be any JSON value. Implementations generating only objects or arrays remain interoperable with all conforming parsers.
This revision removed the RFC 4627 constraint that a JSON text must be an object or array; a JSON text can now be any JSON value. Implementations that generate only objects or arrays remain interoperable as all implementations will accept these.
Unpaired UTF-16 surrogates (e.g., '\uDEAD') are syntactically allowed by the ABNF but produce unpredictable behavior in receiving software, including different string length values or fatal runtime exceptions.
Unpaired UTF-16 surrogates in JSON strings (e.g., '\uDEAD') produce unpredictable behavior in receiving implementations, including differing string length results or fatal runtime exceptions.
UTF-8 encoded JSON texts are interoperable in the sense that they will be read successfully by the maximum number of implementations; many implementations cannot successfully read UTF-16 or UTF-32 encoded texts.
UTF-8-encoded JSON texts are interoperable with the maximum number of implementations; many implementations cannot successfully read UTF-16 or UTF-32 encoded texts.
UTF-8 encoded JSON texts are readable by the maximum number of implementations; many implementations cannot successfully read UTF-16 or UTF-32 encoded JSON.
UTF-8 is the most interoperable encoding; many implementations cannot read UTF-16 or UTF-32. Implementations that generate only objects or arrays remain interoperable since all parsers must accept them.
A JSON generator MUST produce output that strictly conforms to the JSON grammar.
A JSON generator MUST produce text that strictly conforms to the JSON grammar.
A JSON generator produces JSON text, and the resulting text MUST strictly conform to the JSON grammar.
A JSON generator produces JSON text that MUST strictly conform to the JSON grammar.
A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar.
A JSON generator's output MUST strictly conform to the JSON grammar.
A JSON generator's output 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.
Implementations may set limits on text size, nesting depth, number range and precision, and string length and character contents. These limits are permitted but not required.
Implementations MUST NOT add a byte order mark to the beginning of a JSON text. Implementations that parse JSON texts MAY ignore the presence of a byte order mark 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.
Names within a JSON object SHOULD be unique. When names are not unique, behavior of receiving software is unpredictable: some report only the last pair, others error, others report all pairs including duplicates.
The names within a JSON object SHOULD be unique. When names are not unique, behavior is unpredictable: implementations vary between reporting only the last pair, reporting an error, or reporting all pairs including duplicates.
The names within an object SHOULD be unique. When names are not unique, the behavior of software receiving such an object is unpredictable.
A JSON array is an ordered sequence of zero or more values of any type, separated by commas and enclosed in square brackets. There is no requirement that values in an array be of the same type.
A JSON object is an unordered collection of zero or more name/value members, where each name is a string, separated from its value by a colon, and members are separated by commas, enclosed in curly braces. Member ordering is not guaranteed to be visible to calling software.
A JSON text is a serialized value: any JSON value (object, array, number, string, true, false, or null), optionally surrounded by insignificant whitespace. RFC 7159 removes the RFC 4627 constraint that a JSON text must be an object or array.
A JSON text is a serialized value conforming to the grammar `JSON-text = ws value ws`. The value may be any JSON type: object, array, number, string, or the literals false, null, or true. This removes RFC 4627's constraint that a JSON text must be an object or an array.
A JSON text is a serialized value consisting of optional whitespace, a value, and optional whitespace. RFC 7159 removes the RFC 4627 constraint that a JSON text must be an object or array — any JSON value is now a valid JSON text.
A JSON text is a serialized value, defined as 'ws value ws'. This relaxes the RFC 4627 constraint that required a JSON text to be an object or array; any JSON value (string, number, boolean, null, object, or array) is a valid JSON text.
A JSON text is a serialized value; it may be any JSON value (object, array, number, string, boolean, or null), removing the RFC 4627 restriction that constrained it to only objects or arrays.
A JSON text is defined as a serialized value: any JSON value optionally surrounded by insignificant whitespace (JSON-text = ws value ws). This removes the RFC 4627 constraint that a JSON text must be an object or array.
A JSON text is defined as 'ws value ws', where a value may be an object, array, number, string, or one of the literal names false, null, or true. This expands the prior RFC 4627 constraint that required a JSON text to be an object or array.
An array is a pair of square brackets surrounding zero or more comma-separated values. There is no requirement that the values in an array be of the same type.
An array is an ordered sequence of zero or more values enclosed in square brackets, separated by commas. Values in an array are not required to be of the same type.
An array is represented as `begin-array [ value *( value-separator value ) ] end-array`. Elements are separated by commas; there is no requirement that values be of the same type.
An array is represented as '[' followed by zero or more comma-separated values followed by ']'. Values in an array are not required to be of the same type.
An array is represented as square brackets surrounding zero or more values separated by commas: array = begin-array [ value *( value-separator value ) ] end-array. There is no requirement that values be of the same type.
An array is represented as '[' [ value *( ',' value ) ] ']'. Elements are separated by commas and may be of different types.
An array is zero or more values enclosed in square brackets, separated by commas. Values in an array are not required to be of the same type.
An object is a pair of curly brackets surrounding zero or more name/value members, where each name is a string, separated from its value by a colon, and members are separated by commas. Object member names SHOULD be unique.
An object is an unordered collection of name/value pairs enclosed in curly brackets. A name is a string, separated from its value by a colon, with members separated by commas.
An object is an unordered collection of zero or more name/value pairs enclosed in curly brackets. A name is a string followed by a colon; members are separated by commas.
An object is represented as `begin-object [ member *( value-separator member ) ] end-object`, where each member is `string name-separator value`. A name is always a string.
An object is represented as curly brackets surrounding zero or more name/value pairs (members), where a name is a string followed by a colon, with members separated by commas: object = begin-object [ member *( value-separator member ) ] end-object.
An object is represented as '{' followed by zero or more comma-separated 'string : value' members followed by '}'. A name is always a string.
An object is represented as '{' [ member *( ',' member ) ] '}' where each member is a string name-separator value. A colon separates name from value; a comma separates members.
An object is zero or more name/value members enclosed in curly brackets, where each name is a string, separated from its value by a colon, and successive members are separated by commas. The grammar is: `object = begin-object [ member *( value-separator member ) ] end-object`.
JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays). An object is an unordered collection of zero or more name/value pairs; an array is an ordered sequence of zero or more values.
JSON defines six structural characters: begin-array '[' (0x5B), begin-object '{' (0x7B), end-array ']' (0x5D), end-object '}' (0x7D), name-separator ':' (0x3A), and value-separator ',' (0x2C). Insignificant whitespace (space, tab, line feed, carriage return) is allowed before or after any of these.
JSON defines six structural characters: begin-array ([), begin-object ({), end-array (]), end-object (}), name-separator (:), and value-separator (,). Insignificant whitespace (space, horizontal tab, line feed, carriage return) is allowed before or after any structural character.
JSON defines six structural characters: begin-array ([), end-array (]), begin-object ({), end-object (}), name-separator (:), and value-separator (,). Insignificant whitespace (space, tab, line feed, carriage return) is allowed before or after any structural character.
JSON defines six structural characters: 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 of these.
JSON defines six types of values: object, array, number, string, and the three literal names false, null, and true. Objects are unordered name/value pair collections; arrays are ordered sequences of values.
JSON defines six value types: object, array, number, string, and the three literals true, false, and null. These constitute the complete set of JSON values.
JSON defines six value types: object (unordered name/value pairs in curly brackets), array (ordered values in square brackets), number, string, and three literal names (true, false, null).
JSON defines two-character escape sequences for common characters (`\"`, `\\`, `\/`, `\b`, `\f`, `\n`, `\r`, `\t`) and a six-character `\uXXXX` form for any BMP code point. Hex letters A–F may be upper or lower case in `\uXXXX` sequences.
JSON represents four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays). An object is an unordered collection of zero or more name/value pairs; an array is an ordered sequence of zero or more values.
RFC 7159 updates the MIME media type registration for 'application/json'. The registration specifies no required or optional parameters, binary encoding considerations, and no 'charset' parameter (adding one has no effect on compliant recipients). File extension is .json.
The MIME media type 'application/json' is registered for JSON text, with no required parameters, no optional parameters, no charset parameter, file extension '.json', and change controller IESG. This registration updates RFC 4627.
The MIME media type for JSON text is application/json (type: application, subtype: json). The registration includes no required or optional parameters, no charset parameter, and file extension .json. Change controller is IESG.
This document registers and updates the 'application/json' MIME media type. File extension is '.json'; default encoding is UTF-8 (binary encoding considerations apply). No 'charset' parameter is defined; adding one has no effect on compliant recipients.
This document registers and updates the MIME media type `application/json` with IANA. File extension `.json`, no required parameters, no charset parameter defined. Change controller is IESG; security considerations reference RFC 7159 Section 12.
This document registers the MIME media type 'application/json' for JSON text, with no required parameters, no optional parameters, UTF-8/16/32 encoding, and file extension '.json'. Change controller is IESG. No 'charset' parameter is defined; adding one has no effect on compliant recipients.
This document updates the MIME media type registration for 'application/json'. Type: application, Subtype: json. No required or optional parameters. File extension: .json. The registration was originally created by RFC 4627.
JSON is a subset of JavaScript but deliberately excludes assignment and invocation, limiting its attack surface relative to full JavaScript execution. However, the syntactic overlap makes naive use of language-native eval mechanisms dangerous.
JSON is a subset of JavaScript but excludes assignment and invocation. While this reduces risk relative to arbitrary JavaScript, the syntactic similarity to JavaScript means eval()-based parsing remains dangerous.
JSON is a subset of JavaScript that excludes assignment and invocation, making it safer than arbitrary JavaScript, but security issues persist with scripting language parsers that process JSON.
JSON syntax is borrowed from JavaScript, making it possible to use JavaScript's eval() function to parse JSON texts. This constitutes an unacceptable security risk because the text could contain executable code along with data declarations. The same risk applies to eval()-like functions in any language where JSON texts conform to that language's syntax.
Using a language's eval() function (or equivalent) to parse JSON texts constitutes an unacceptable security risk because the text may contain executable code alongside data declarations. This applies to JavaScript and any other language in which JSON syntax is a subset of the language syntax.
Using a language's `eval()` function to parse JSON texts constitutes an unacceptable security risk, since JSON text could contain executable code along with data declarations. This applies to JavaScript and any other language whose syntax is a superset of JSON.
Using JavaScript's eval() function (or analogous functions in other languages) to parse JSON texts constitutes an unacceptable security risk, since the text could contain executable code along with data declarations. JSON parsers should be used instead.
Using JavaScript's eval() function or equivalent eval-like functions in other languages to parse JSON texts constitutes an unacceptable security risk, because the text could contain executable code alongside data declarations. JSON is a subset of JavaScript syntax but excludes assignment and invocation.
Using JavaScript's eval() function (or equivalent in any language where JSON texts conform to that language's syntax) to parse JSON constitutes an unacceptable security risk, because the text could contain executable code alongside data declarations.
Using JavaScript's eval() function (or eval()-like functions in other languages) to parse JSON texts constitutes an unacceptable security risk because the text could contain executable code along with data declarations. JSON is a subset of JavaScript that excludes assignment and invocation, but eval() does not enforce this constraint.
Using JavaScript's eval() function or similar eval-like functions in any programming language to parse JSON texts constitutes an unacceptable security risk, since the text could contain executable code along with data declarations.
Using JavaScript's eval() or equivalent functions in other languages to parse JSON texts constitutes an unacceptable security risk, since the text could contain executable code along with data declarations.
A JSON number is base-10 with an optional leading minus sign, no leading zeros, an optional fraction part (decimal point followed by one or more digits), and an optional exponent part (E or e, optional sign, one or more digits). Infinity and NaN are not permitted.
A JSON number is encoded in base 10 with an optional minus sign, integer part (no leading zeros), optional fraction (decimal point followed by one or more digits), and optional exponent (E or e, optional sign, one or more digits). Infinity and NaN are not permitted.
A JSON number is 'number = [minus] int [frac] [exp]' in base 10. Leading zeros are not allowed, Infinity and NaN are not permitted, and the exponent uses 'e' or 'E' optionally followed by a sign and digits.
A JSON number is represented as '[ minus ] int [ frac ] [ exp ]' in base 10. Leading zeros are not allowed; Infinity and NaN are not permitted. The exponent part begins with 'e' or 'E' optionally followed by '+' or '-' and one or more digits.
A JSON number is represented in base 10: an optional minus sign, an integer part (no leading zeros), an optional fraction part (decimal point followed by one or more digits), and an optional exponent part (e or E, optional sign, one or more digits). Infinity and NaN are not permitted.
A JSON string begins and ends with quotation marks (%x22). All Unicode characters may appear unescaped except quotation mark, reverse solidus, and control characters U+0000–U+001F. BMP characters may be escaped as \uXXXX (six characters); non-BMP characters are encoded as a 12-character UTF-16 surrogate pair (e.g., \uD834\uDD1E for U+1D11E).
A JSON string is a sequence of Unicode characters enclosed in quotation marks. Characters that MUST be escaped include: quotation mark (U+0022), reverse solidus (U+005C), and control characters U+0000 through U+001F. BMP characters may use \uXXXX six-character sequences; non-BMP characters require a 12-character UTF-16 surrogate pair escape.
A JSON string is delimited by quotation marks (%x22). Characters that MUST be escaped include quotation mark, reverse solidus, and control characters U+0000 through U+001F. Non-BMP characters are encoded as 12-character UTF-16 surrogate pair escape sequences (\uHHHH\uHHHH).
A JSON string is enclosed in quotation marks (0x22). All Unicode characters are permitted except those that must be escaped: quotation mark, reverse solidus, and control characters U+0000 through U+001F. Non-BMP characters are encoded as a 12-character UTF-16 surrogate pair escape sequence.
A JSON string is encoded as 'quotation-mark *char quotation-mark'. Characters that must be escaped include quotation mark, reverse solidus, and control characters U+0000 through U+001F. Non-BMP characters are encoded as a 12-character UTF-16 surrogate pair escape sequence (e.g., "\uD834\uDD1E" for U+1D11E).
A JSON text is defined as optional insignificant whitespace surrounding a single value: `JSON-text = ws value ws`. Insignificant whitespace consists of space (0x20), horizontal tab (0x09), line feed (0x0A), and carriage return (0x0D).
A JSON text is defined as 'ws value ws', where ws is any combination of space (0x20), horizontal tab (0x09), line feed (0x0A), and carriage return (0x0D). Six structural characters are defined: begin-array ([), end-array (]), begin-object ({), end-object (}), name-separator (:), and value-separator (,).
A JSON text is defined by the grammar 'JSON-text = ws value ws', where whitespace (ws) consists of space (0x20), horizontal tab (0x09), line feed (0x0A), and carriage return (0x0D). Six structural characters delimit objects and arrays using '{', '}', '[', ']', ':', and ','.
A number is represented as '[ minus ] int [ frac ] [ exp ]' in base 10. Leading zeros are not allowed. Infinity and NaN are not permitted. The exponent marker may be 'e' or 'E'.
A string begins and ends with quotation marks (U+0022). Control characters U+0000 through U+001F, quotation mark, and reverse solidus must be escaped. BMP characters may use \uXXXX (6-char) sequences; non-BMP characters use 12-character UTF-16 surrogate pair sequences.
A string is a sequence of Unicode characters enclosed in quotation marks (%x22). Characters that MUST be escaped are the quotation mark, reverse solidus, and control characters U+0000 through U+001F. Escape sequences use a leading reverse solidus; BMP characters use \uXXXX (6 chars); characters outside the BMP use a 12-character UTF-16 surrogate pair sequence.
A string is delimited by quotation marks (0x22). Characters U+0000 through U+001F, quotation mark, and reverse solidus MUST be escaped. Non-BMP characters are encoded as 12-character UTF-16 surrogate pair sequences (e.g., '\uD834\uDD1E').
A string is delimited by quotation marks (U+0022) and may contain any Unicode character except those that must be escaped: quotation mark, reverse solidus, and control characters U+0000–U+001F. Escape sequences are \uXXXX (six characters) or two-character shortcuts (\b, \f, \n, \r, \t, \\, \/, \").
A string is zero or more Unicode characters enclosed in quotation marks (%x22). Characters U+0000–U+001F, quotation mark, and reverse solidus must be escaped. Escape sequences use `\uXXXX` (six characters) for BMP characters or a 12-character UTF-16 surrogate pair sequence for characters outside the BMP.
An object is encoded as a pair of curly brackets surrounding zero or more name/value members. Each member consists of a string name, a colon name-separator, and a value; members are separated by commas. `object = begin-object [ member *( value-separator member ) ] end-object`.
An object is encoded as 'begin-object [ member *( value-separator member ) ] end-object' where member is 'string name-separator value'. Members are separated by commas and names from values by colons.
An object is represented as '{' followed by zero or more name/value pairs separated by commas, where each pair separates the name string and value with a colon, enclosed by '}'. An array is '[' followed by zero or more comma-separated values enclosed by ']'.
Characters outside the Basic Multilingual Plane (above U+FFFF) are encoded in JSON strings as 12-character UTF-16 surrogate pair sequences: \uHHHH\uHHHH. For example, the G clef (U+1D11E) is represented as '\uD834\uDD1E'.
JSON defines six structural characters: begin-array (%x5B '['), begin-object (%x7B '{'), end-array (%x5D ']'), end-object (%x7D '}'), name-separator (%x3A ':'), and value-separator (%x2C ','). Insignificant whitespace (space %x20, tab %x09, line feed %x0A, carriage return %x0D) is allowed before or after any structural character.
JSON defines six structural characters encoded as specific byte values: begin-array (%x5B), end-array (%x5D), begin-object (%x7B), end-object (%x7D), name-separator/colon (%x3A), and value-separator/comma (%x2C). Insignificant whitespace (space %x20, tab %x09, line feed %x0A, carriage return %x0D) is allowed before or after any structural character.
JSON grammar defines six structural characters: begin-array (%x5B), begin-object (%x7B), end-array (%x5D), end-object (%x7D), name-separator (%x3A colon), and value-separator (%x2C comma). Insignificant whitespace (space, tab, line feed, carriage return) is allowed before or after any structural character.
JSON literals are encoded as exact byte sequences: false = %x66.61.6c.73.65, null = %x6e.75.6c.6c, true = %x74.72.75.65.
JSON numbers are base-10, composed of an optional minus sign, an integer part (no leading zeros), an optional fractional part (decimal point followed by one or more digits), and an optional exponent part (E/e, optional sign, one or more digits). Infinity and NaN are not permitted.
JSON numbers use base-10 decimal with an optional minus sign, integer part (no leading zeros), optional fraction (decimal point followed by one or more digits), and optional exponent (E or e, optional sign, one or more digits). Infinity and NaN are not permitted.
JSON object structure: `begin-object [ member *( value-separator member ) ] end-object`, where `member = string name-separator value`. Array structure: `begin-array [ value *( value-separator value ) ] end-array`.
JSON strings begin and end with quotation marks (%x22). Control characters U+0000–U+001F, quotation mark, and reverse solidus MUST be escaped. Non-BMP characters are encoded as 12-character UTF-16 surrogate pair escape sequences (e.g., '\uD834\uDD1E' for U+1D11E).
JSON text is defined as optional whitespace surrounding a value: `JSON-text = ws value ws`. Insignificant whitespace (space 0x20, tab 0x09, line feed 0x0A, carriage return 0x0D) is allowed before or after any of the six structural characters.
JSON values are encoded as tokens: the literals 'false' (0x66.61.6c.73.65), 'null' (0x6e.75.6c.6c), and 'true' (0x74.72.75.65) are fixed-byte sequences; strings are delimited by quotation marks (0x22); structural characters are single ASCII bytes.
Numbers are base-10, with an optional leading minus sign, an integer part (no leading zeros), an optional fraction part (decimal point followed by one or more digits), and an optional exponent part (E/e with optional sign and digits). Infinity and NaN are not permitted.
Numbers are base-10 with an optional minus sign, integer part (no leading zeros), optional fraction (decimal point followed by one or more digits), and optional exponent (E/e with optional sign followed by digits). Infinity and NaN are not permitted.
Numbers are base-10 with optional leading minus, optional fraction (decimal point followed by one or more digits), and optional exponent (E or e, optional sign, one or more digits). Leading zeros are not allowed. Infinity and NaN are not permitted.
Numbers are represented in base 10 with an optional leading minus sign, an integer component (no leading zeros), an optional fraction (decimal point followed by one or more digits), and an optional exponent (E or e, optional sign, one or more digits). Infinity and NaN are not permitted. Grammar: `number = [ minus ] int [ frac ] [ exp ]`.
Numbers are represented in base 10 with optional minus sign, integer component (no leading zeros), optional fraction (decimal point followed by digits), and optional exponent (E/e with optional sign followed by digits). Values like Infinity and NaN are not permitted.
Six structural characters define JSON's grammar: begin-array (%x5B '['), begin-object (%x7B '{'), end-array (%x5D ']'), end-object (%x7D '}'), name-separator (%x3A ':'), and value-separator (%x2C ','). Insignificant whitespace (space %x20, tab %x09, line feed %x0A, carriage return %x0D) is allowed before or after any structural character.
Six structural characters delimit JSON structures: `[` (begin-array, %x5B), `]` (end-array, %x5D), `{` (begin-object, %x7B), `}` (end-object, %x7D), `:` (name-separator, %x3A), and `,` (value-separator, %x2C). Insignificant whitespace (space %x20, tab %x09, line feed %x0A, carriage return %x0D) is permitted before or after each.
String escape sequences: '\"' (quotation mark), '\\' (reverse solidus), '\/' (solidus), '\b' (backspace), '\f' (form feed), '\n' (line feed), '\r' (carriage return), '\t' (tab), '\uXXXX' (Unicode code point in BMP using four hex digits).
String escape sequences use a leading reverse solidus followed by one of: '"', '\', '/', 'b' (backspace), 'f' (form feed), 'n' (line feed), 'r' (carriage return), 't' (tab), or 'uXXXX' (four hex digits for Unicode code point).
String escape sequences use reverse solidus (\) followed by one of: '"', '\', '/', 'b' (backspace), 'f' (form feed), 'n' (line feed), 'r' (carriage return), 't' (tab), or 'uXXXX' (four hex digits). Hex letters A–F may be upper or lower case.
Strings begin and end with quotation mark (U+0022). Characters that must be escaped include quotation mark, reverse solidus, and control characters U+0000–U+001F. Non-BMP characters are encoded as 12-character UTF-16 surrogate pair sequences (e.g., '\uD834\uDD1E' for U+1D11E).
Strings begin and end with quotation marks (0x22). Characters that must be escaped include quotation mark, reverse solidus, and control characters U+0000 through U+001F. Non-BMP characters are encoded as a 12-character UTF-16 surrogate pair escape sequence (e.g., `\uD834\uDD1E` for U+1D11E).
Strings begin and end with quotation marks (U+0022). Characters that must be escaped include quotation mark, reverse solidus, and control characters U+0000 through U+001F. Characters in the BMP may be escaped as \uXXXX; non-BMP characters require a 12-character UTF-16 surrogate pair sequence.
The six structural characters are: begin-array `[` (0x5B), begin-object `{` (0x7B), end-array `]` (0x5D), end-object `}` (0x7D), name-separator `:` (0x3A), and value-separator `,` (0x2C), each optionally surrounded by whitespace.
The six structural characters are: begin-array '[' (%x5B), begin-object '{' (%x7B), end-array ']' (%x5D), end-object '}' (%x7D), name-separator ':' (%x3A), and value-separator ',' (%x2C). Each may be preceded or followed by insignificant whitespace (space %x20, horizontal tab %x09, line feed %x0A, carriage return %x0D).
The three JSON literal values are encoded as exact byte sequences: false = %x66.61.6c.73.65, null = %x6e.75.6c.6c, true = %x74.72.75.65.
The three literal names are encoded as fixed byte sequences: false = 0x66.61.6c.73.65, null = 0x6e.75.6c.6c, true = 0x74.72.75.65.
The top-level grammar rule is: JSON-text = ws value ws. This document expands the RFC 4627 definition, which constrained a JSON text to be an object or array, to allow any JSON value at the top level.
Two-character escape sequences are defined for common characters: \" (quotation mark), \\ (reverse solidus), \/ (solidus), \b (backspace U+0008), \f (form feed U+000C), \n (line feed U+000A), \r (carriage return U+000D), \t (tab U+0009), and \uXXXX for arbitrary code points.