Editing JSON (section)

=== Data types ===
JSON's basic data types are:

* Number: a signed decimal number that may contain a fractional part and may use exponential [[E notation]] but cannot include non-numbers such as [[NaN]]. The format makes no distinction between integer and floating-point. JavaScript uses [[IEEE-754]] [[double-precision floating-point format]] for all its numeric values (later also supporting [[Arbitrary-precision arithmetic|BigInt]]<ref>{{cite web |title=BigInt - MDN Web doc glossary |url=https://developer.mozilla.org/en-US/docs/Glossary/BigInt |website=Mozilla |access-date=18 October 2020}}</ref>), but other languages implementing JSON may encode numbers differently.
* [[String (computer science)|String]]: a sequence of [[empty string|zero]] or more [[Unicode]] characters. Strings are delimited with double quotation marks and support a backslash [[Escape character|escaping]] syntax.
* [[Boolean data type|Boolean]]: either of the values <code>true</code> or <code>false</code>
* [[Array data structure|Array]]: an [[List (abstract data type)|ordered list]] of zero or more elements, each of which may be of any type. Arrays use [[square bracket]] notation with comma-separated elements.
* [[Object (computer science)|Object]]: a collection of [[name–value pair]]s where the names (also called keys) are strings. The current ECMA standard states, "The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs."<ref>{{harvnb|ref=ecma2017|ECMA-404, 2nd ed.|page=3}}: "The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs."</ref> Objects are delimited with [[Braces (punctuation)#Braces|curly brackets]] and use commas to separate each pair, while within each pair, the colon ':' character separates the key or name from its value.
* <code>[[Nullable type|null]]</code>: an empty value, using the word <code>null</code>

[[Whitespace character|Whitespace]] is allowed and ignored around or between syntactic elements (values and punctuation, but not within a string value). Four specific characters are considered whitespace for this purpose: [[Space (punctuation)|space]], [[horizontal tab]], [[line feed]], and [[carriage return]]. In particular, the [[byte order mark]] must not be generated by a conforming implementation (though it may be accepted when parsing JSON). JSON does not provide syntax for [[Comment (computer programming)|comments]].<ref name=DouglasCrockfordComments/>

Early versions of JSON (such as specified by {{IETF RFC|4627}}) required that a valid JSON text must consist of only an object or an array type, which could contain other types within them. This restriction was dropped in {{IETF RFC|7158}}, where a JSON text was redefined as any serialized value.

Numbers in JSON are agnostic with regard to their representation within programming languages. While this allows for numbers of [[arbitrary precision]] to be serialized, it may lead to portability issues. For example, since no differentiation is made between integer and floating-point values, some implementations may treat <code>42</code>, <code>42.0</code>, and <code>4.2E+1</code> as the same number, while others may not. The JSON standard makes no requirements regarding implementation details such as [[Arithmetic overflow|overflow]], [[underflow]], loss of precision, rounding, or [[signed zero]]s, but it does recommend expecting no more than [[IEEE 754]] [[binary64]] precision for "good interoperability". There is no inherent precision loss in serializing a machine-level binary representation of a floating-point number (like binary64) into a human-readable decimal representation (like numbers in JSON) and back; there exist published algorithms to do this conversion exactly and optimally.<ref>{{cite report |last1=Andrysco |first1=Marc |last2=Jhala |first2=Ranjit |last3=Lerner |first3=Sorin |date=18 February 2016 |url=https://cseweb.ucsd.edu/~mandrysc/pub/dtoa.pdf |title=Printing Floating-Point Numbers: An Always Correct Method |access-date=2025-05-31}}</ref>

Comments were intentionally excluded from JSON. In 2012, Douglas Crockford described his design decision thus: "I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability."<ref name=DouglasCrockfordComments>{{cite web |last=Crockford |first=Douglas |title=Comments in JSON |date=2012-04-30 |url=https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr |archive-url=https://archive.today/20150704102718/https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr |archive-date=2015-07-04 |url-status=dead |quote=I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through [[JSMin]] before handing it to your JSON parser. |access-date=2019-08-30 }}</ref>

JSON disallows "trailing commas", a [[Comma#Computing|comma]] after the last value inside a data structure.<ref>{{Cite web |date=2023-09-12 |title=Trailing commas - JavaScript {{!}} MDN |url=https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Trailing_commas |access-date=2023-12-16 |website=developer.mozilla.org |language=en-US}}</ref> Trailing commas are a common feature of [[#Derivatives|JSON derivatives]] to improve ease of use.<ref name="json5">{{cite web |title=JSON5 |url=https://json5.org/ |publisher=json5 |archive-url=https://web.archive.org/web/20201129113821/https://json5.org/ |access-date=16 December 2020|archive-date=2020-11-29 }}</ref>