Talk:JSON/Archive 2

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Archive 1 Archive 2


YAML comparison

It seems that the YAML comparison section is again becoming more of an evangelism forum (pushing the WP:NOR and WP:NPOV boundaries) and contains both stylistic problems as well as factual errors. (It should also be noted that some of these same comparison problems are also repeated on the YAML article.)

"With the exception of comment strings, JSON is entirely[1] a subset of YAML."

Although casual observation may lead one to this conclusion, the statement is wrong (and it is not obvious that the one cited reference is either notable or reliable, per WP:RELY). From direct examination of the JSON specification (RFC 4627) and the YAML specification [2] (titled "Working Draft 2004-12-28" as of 2007-09-15), there exist valid JSON documents which YAML does not permit. Just some of the incompatibilities include:

  • UTF-32: JSON requires all parsers to accept UTF-32 encoding, YAML disallows UTF-32.
  • Tabs: JSON liberally permits tab characters (U+0009), such as surrounding "structural characters"; YAML is more restrictive.
  • Linebreaks: JSON allows line break characters (such as U+000A) to appear inside double-quoted strings where they are interpreted literally, while YAML will invoke multi-line folding on such a sequence.
  • Unescaped characters: JSON permits any unicode character (except U+0000..U+001F, U+0022, U+005C) to appear within a double-quoted string un-escaped; YAML disallows some of these. For example the non-printable character U+003B is permitted in JSON but disallowed in YAML.
  • Non-BMP characters: JSON allows Unicode characters outside the BMP to be represented by a double-surrogate-escape syntax, for example "\uD834\uDD1E" which is interpreted as U+1D11E; YAML does not permit this (since each \u escape is treated independently and it does not allow such escapes to evaluate to a surrogate codepoint).

Additionally the "exception of comment strings" remark makes little sense as JSON does not support a comment string.

[...]it enforces avoidance of the security pitfall of using a built-in interpreter to evaluate code into native data structures.

This is not entirely true either. Granted, it is unlikely that JavaScript programs will attempt to knowingly parse YAML documents using the eval() function as is frequent with JSON. But eval() is not the only way to get YAML to be evaluated by the JavaScript interpreter. YAML documents could still be subject to similar cross-site request forgery attacks, specifically because some YAML documents are also valid JSON (or more importantly are valid JavaScript). Those subsets of YAML documents are just as XSRF vulnerable as is JSON. So it's not an entirely false statement, but not entirely true either; and regardless it is bordering on original research. --Dmeranda 06:28, 15 September 2007 (UTC)

Don't forget about commas: [ 1,23 ] parses as [ 1, 23 ] in JSON but [ 123 ] in YAML. It's very misleading to say that JSON is a subset of YAML and I think that the sentence you quoted should be removed since it's wrong on both counts. TomJF 21:38, 23 September 2007 (UTC)

CHANGED: I updated the YAML comparison section to have a NPOV and to enumerate the distinguishing characteristics with specific factual, rather than opinionated and arguably misleading, content. There is a danger that some JSON evangelists might still consider any comparisons to another format as blasphemy. However the entire section on comparison to other related formats is absolutely essential to an article of this type. It serves multiple purposes and in this case it has the added bonus of permitting a terse discussion of serialization concepts that have no expression in JSON. This is perhaps a best way to enumerate such issues in languages (e.g. contrast this with the rather unhelpful dog's dinner of listed defects in XML on the XML page, which don't teach the user anything helpful since you can't actually understand them without a comparison of how it could be done differently.) By giving concrete comparisons: e.g. XML has the notion of validation as well as well-formed. YAML has the notion of Relational data. The reader has some concrete points of comparison and it avoids becoming abstract criticism. Cems2 23:46, 21 October 2007 (UTC)

I also deleted the point of distinction on YAML lacking JSON's eval security pitfall. I'm not sure I should have done that. The argument against removing it is that in the real world it's one of the most expensive and common pitfalls, so ignoring it is like ignoring the elephant in the room and does the reader poorly with a lack of teaching. The argument for removing it is that it's not really a difference is syntax which is what that paragraph is about, it's simply a pragmatic issue. In theory both languages are equally secure so including it lacks a certain NPOV quality in favor of YAML, since user experience is the difference.Cems2 23:46, 21 October 2007 (UTC)

References to software implementations

I've written the M's JSON library, which is a JSON parser written in C. The project is hosted by sourceforge and it's listed as the top JSON project in, which isn't much. Yet, I do believe that a link to the project's site should be included in the reference section. As I'm the project's author, I don't believe it would be right for me to add it there. So, can anyone add a reference to it? The project page is [3] --Mecanismo | Talk 16:07, 8 December 2007 (UTC)

Thanks for making your software available for others; unfortunately Wikipedia is not really the right place to link to this, see WP:NOT#LINK. Since there are probably over 50 different JSON implementations, linking to each would quickly overwhelm the external links section. Fortunately the website seems to serve that purpose well: as a nearly comprehensive list of implementations and links to them. I see that your "M" C implementation is already listed on that site. For anybody else's project, please consider getting your site listed on the list rather than adding links in this article. On the other hand, links to topical information about JSON (rather than just software libraries) may be appropriate for linking here. - Dmeranda (talk) 19:22, 10 December 2007 (UTC)


There are two versions of potentially equivalent XML provided on the page, with the one used for size comparison bending the implied semantics of the example to collapse an array of phone numbers into a single tag. This likely invalidates the example for size comparison purposes. (talk) 00:45, 19 July 2010 (UTC)

Is it possible to add and delete records/items in a JSON object using JavaScript? If no, this should be mentioned under the section about comparison. (talk) 15:45, 6 January 2008 (UTC)

delete (talk) 05:18, 6 March 2008 (UTC)

The first version of XML is not equivalent to the second, or to the JSON. In particular, element descendants are always ordered (even if that ordering is ignored by the consumer of the data), whereas a JSON object is always unordered. So the XML contains more information. In effect, the first version of XML corresponds to a nested array of objects (some of which have a single key:value pair).

The second example is limited because attribute values in XML are not equivalent to JSON values. In particular, XML attributes cannot be nested. It is possible to use attribute values as references, or stuff them with specially encoded representations, neither of which are within the direct purview of XML.

JSON is a broad but still special case initialization notation and I don't think it can directly represent all JavaScript objects. Any String, Number, or Array with attached properties must be expressed indirectly and handled in application code. As noted, there are also several unsupported JavaScript data types. XML can express these, but again handling the conversion is application or library code (just as it is with JSON), not something that XML handles directly. The XML syntax does not have to be extended to express the relationships or types (though the tag set does). Applications are left with the responsibility for enabling such mappings in both XML and JSON. — Preceding unsigned comment added by (talk) 16:31, 10 December 2011 (UTC)

Associative Array

JSON is not an associative array if I'm reading the articles right. It appears like one, but isn't one. Correct? -- (talk) 14:12, 15 March 2008 (UTC)

No, the JS Object type is an associative array. EdC (talk) 14:06, 16 March 2008 (UTC)
I think it is fair to say that the JSON "object" type is an associative array, or is meant to be interpreted as one. The main difference between the JavaScript Object and the JSON object is that in JSON only strings may be used as keys. However, remember that JSON is only a representational data format, so there are no requirements that any particular algorithm or data structure (e.g., hash tables) must be used by any software implementing the JSON specification. -- Dmeranda (talk) 05:05, 17 March 2008 (UTC)


The section on CSRF security risks contained incorrect information. I have removed it and replaced it with correct information, but do not want to clutter the main page with a bunch of references about why the old stuff was wrong. So, here.

Per Joe Walker, using an array as the outer container is indeed insecure and can lead to data theft. His followup about stealing data from objects assumes that the data sent will be in the form "({...})". However, this is actually *invalid* JSON. Valid JSON using the "{...}" format is not vulnerable, because a syntax error will be raised before any attribute assignments are executed. Tom Hughes-Croucher writes about this. John Millikin (talk) 03:02, 30 March 2008 (UTC)

JavaScript eval

This statement:

   eval is meant for JavaScript, not for JSON; using it for such is abusing the interface

appears to be unsubstantiated and sufficiently ambiguous as to warrant a citation. Absent that, it appears to be inappropriate editorializing on the subject matter of this article.

For example, the relevant section of the article does not cite any authoritative source to support the claim of what JavaScript eval() is "meant" for. Similar problems apply to the assertion of "abuse".

If there is a normative statement to be made about the "proper" practices of JavaScript coding, it belongs in an article on JavaScript. Moreover, even in a JavaScript article, such normative claims would be inappropriate unless properly attributed to a reliable source as a statement of such-and-such person's opinion, industry convention, or whatever.

Please help to keep this article as neutral, well-substantiated and objective as possible. Thanks. dr.ef.tymac (talk) 00:50, 21 April 2008 (UTC)

It is fine to request citations on merit, but please don't be so quick to cast judgments concerning perceived editorializing. Omission of this information is itself a form of editorializing.
I am beginning to have doubts whether this entire section, Security issues, even belongs in this article. None of this directly concerns JSON, the language-independent data interchange format; it is all about the security or insecurity of one particular method used by one particular language, JavaScript. In fact JSON is not even needed for this JavaScript security problem; one could try using eval to process a calculator language expression; and would similarly see the exact same security problems. Perhaps this material is better moved to eval, JavaScript, AJAX, or some such page where it may have more relevance.
As far as what eval was meant for, I will grant that perhaps the word "meant" should instead read "is required to do", as it would not require any subjective determination of motive (since the ECMAScript standard does not include a non-normative rationale section as some other language standards do). Additionally, eval clearly predated the existence of JSON and so was certainly not meant to process JSON (even though it may be made to do so): ECMAScript r3 was published in 1999, and the website didn't exist until 2000, with JSON only being standardized as an RFC in 2006. Anyway, concerning what eval does, straight from the normative reference ECMA-262, 3rd Ed. Dec. 1999:

10.1.2 Type of Executable Code

Eval code is the source text supplied to the built-in eval function. More precisely, if the parameter to the built-in eval function is a string, it is treated as an ECMAScript Program [emphasis added]. The eval code for a particular invocation of eval is the global code portion of the string parameter.
... eval(x)
When the eval function is called with one argument x, the following steps are taken:
1. If x is not a string value, return x.
2. Parse x as a Program. If the parse fails, throw a SyntaxError exception (but see also clause 16).
3. Evaluate the program from step 2.

At no place does the standard make any notion of demarshaling JSON-encoded data, or data in any other format for that matter. It is very explicit about evaluating only a "JavaScript Program". So it should be a non-controversial statement and very clearly supported that eval was meant for JavaScript (albeit a better choice of words could be used for meant). One needs to be careful of conflating JSON (type "application/json" per RFC 4627) with JavaScript (type "application/javascript" per ECMA-262). Furthermore, as it is very clearly documented in a normative manner that any string you pass into eval will be treated as if it is an ECMAScript Program; any caller of eval is thereby making an implied claim that the provided string argument is in fact ECMAScript. Therefore, knowingly passing in JSON data to eval is by any strict interpretation misrepresenting the type of the data. Please note this is not a judgment on whether this is correct or reasonable or good or bad; it is a factual technical statement of an intentional type-mismatch. Just a using a C-style cast is misrepresenting the type; it may be a perfectly okay thing to do, but it is still intentional misrepresentation. In as much as this is the root cause of many security issues, it is worthy of mention. -- Dmeranda (talk) 05:59, 21 April 2008 (UTC)

Review of Dmeranda's "intentional misrepresentation" analysis

Your analysis contains some substantiated information, however none of the substantiated information is under dispute. What is under dispute are the parts of your analysis that seem to derive from wholly unsubstantiated origins.
For review:
  • One needs to be careful of conflating JSON with JavaScript
The validity of this point is not at issue, the issue is that all material claims put forward in this article need to have some basis in citable, relevant authority.
  • At no place does the standard make any notion of demarshaling JSON-encoded data.
Nor have you provided a cite to the standard (or any other relevant source for that matter) that specifies an unambiguous method for distinguishing an instance of JSON from an instance of JavaScript, in those cases where syntax of each is mutually indistinguishable.
If you wish to emphasize this distinction, please provide some authority for it.
  • any caller of eval is making an implied claim that the provided string argument is in fact ECMAScript
This is a serious deficiency of your analysis. It entirely lacks support. The same goes for your use of the terms "misrepresent", "abuse", "meant", "intended", "intentional misrepresentation" and others.
For example, the ECMAScript specification states in relevant part:
   An implementation may treat any instance of the following kinds of runtime errors 
   as a syntax error
the specification also states ...
   An implementation may report syntax errors in eval code
Unless you can provide reliable support to the contrary, these terms clearly and completely refute any claim that eval code that is not valid ECMAScript code somehow constitutes a kind of "abuse" or "intentional misrepresentation".
Clearly, your "intentional misrepresentation" theory needs either a citation and much better support, or it needs to go somewhere else besides a WP article. dr.ef.tymac (talk) 15:00, 21 April 2008 (UTC)

Native client-side support for JSON

Native support is coming soon. IE8 and Firefox 3.1. I think this should be noted --Voidvector (talk) 05:50, 11 December 2008 (UTC)

Cross-site request forgery

Note that the section in which script inclusion attacks are called a variant of XSRF directly contradicts the XSRF article, which defined XSRF attacks as a wholly different animal, and specifically says they are "blind" (e.g., data is posted, but cannot be read back). Sadly, this misnomer is repeated on a number of sites; a more appropriate, but slightly less popular name is "cross-site script inclusion". We might want to either stop calling it XSRF and use XSSI instead, or at least resolve the conflict by saying that the current name is not technically accurate. --lcamtuf (talk) 22:24, 11 January 2009 (UTC)

I believe the appropriate term is term is Cross-Site Scripting (XSS), rather than XSSI. (talk) 10:01, 4 January 2012 (UTC)

in general, JSON is neither valid YAML nor valid ecmascript

The following JSON text is not valid YAML, as YAML does not support surrogate codepoint encoding, while JSON requires it for non-BMP characters:


This is a problem in practise, as it makes JSON non-interoperable with YAML with non-BMP characters. Also, YAML puts a limit of 1024 characters on the length of strings used as object property names in JSON notation, while JSON does have no such limit.

Similarly, the following JSON text (where \x2028 stands for the literal U+2028 character) is a valid JSON text, but not valid ECMAscript, as ecmascript disallows literal U+2028 characters in string literals:


This also comes up in practise, as JSON generators usually do not escape those characters, as this is not required by JSON.

So all claims that YAML is a superset of JSON, or JSON is a subset of ecmascript, are wrong, and should be removed.

Also, the article keeps having statements like "JSON is a YAML subset, you only have to remove ...". Do not do this: if you have to change JSON texts before it becomes valid YAML, it isn't a subset. (talk) —Preceding undated comment was added on 22:53, 17 February 2009 (UTC).

No clue about your YAML comment, since I am not familiar with it. "\x2028" is not valid JSON, because JSON spec does not support "\x" (see this chart). It is valid ECMAScript. In ECMAScript it is " 28" because "\x20" is the space character. --Voidvector (talk) 02:42, 18 February 2009 (UTC)
*sigh. I explicitly wrote that \x2028 is the literal U+2028 character - please read what I wrote, not just the two indented lines. (talk) —Preceding undated comment was added on 01:11, 19 February 2009 (UTC).
Regardless of what your own interpretation of "\x2028" is, it does not represent "U+2028" in JSON or ECMAScript. --Voidvector (talk) 02:13, 19 February 2009 (UTC)
OMG. I never claimed it would represent U+2028 in JSON. Please care to *read* what I wrote. I claimed it represents U+2028 _in the example only_. You are supposed to replace it by an actual U+2028 character when trying out the example. Thats what *literal* means. The example *is* a valid JSON text, but *not* valid ecmascript. (talk) —Preceding undated comment was added on 04:54, 19 February 2009 (UTC).
GP is correct — you're reading his post incorrectly. He's not trying to say that "\x2028" is valid JSON, he's trying to say, "when you read this snippet, in your head, replace '\x2028' with U+2028." He doesn't want to actually put a U+2028 in the example itself, as this would be confusing (U+2028 is a line separator; it would be invisible), thus, he's using the pseudo syntax "\x2028" to represent it. GP would also appear to be correct in his overall point: JSON is not a subset of JavaScript. Deathanatos (talk) 01:32, 28 July 2012 (UTC)

Updated YAML spec

The YAML 1.2 specification also explicitly states:

"Note version 1.2 is mostly a superset of version 1.1, defined for the purpose of ensuring JSON compatibility." (see Section 6.8.1. “YAML” Directives [4]) Peak (talk) 05:08, 20 February 2009 (UTC)


onreadystatachange should be set before calling send() —Preceding unsigned comment added by (talk) 16:07, 3 June 2009 (UTC)

Pronunciation of "JSON"

(pronounced /ˈdʒeɪsɒn/, i.e., "Jason")

I (a native speaker from Michigan) pronounce "Jason" as /ˈdʒeɪsʌn/ (or, reduced, /ˈdʒeɪsən/ or /ˈdʒeɪsɨn/). In other words, I rhyme the last syllable with "run" and "fun", not with the /ɒ/ in "on" or "con". So I think one of the pronunciations in the article now is wrong. I couldn't find an official pronunciation on

--Arundelo (talk) 16:10, 30 June 2009 (UTC)

I've removed the pronunciation altogether. The IPA wasn't complete with regards to emphasis (and I don't know how to fix it), and didn't even match the pronunciation of Jason. I suggest not putting one, or putting multiple up pronunciations, with a possible section in the article about it. I can't find an official pronunciation, nor a reliable source that says how it is pronounced, and I'm pretty sure developers are split on it. Some say it's like the name Jason, while others pronounce it Jay-sawn. I've always pronounced it Jay-sawn, but that's just how my mind thinks it would be pronounced with English pronunciation rules (I'll see if I can come up with why). -- Austin512 (talkcontribs) 04:21, 2 August 2009 (UTC)

According to coiner Crockford as quoted at StackOverflow, he "strictly" does not care about its pronunciation, but says it like "Jason" most of the time, himself. He riddiculed the argument by asserting a nasal French pronunciation, like "Je Só(n)". As for normal English rules, perhaps it depends whether you consider it JS-ON (like "Jace on") or J-SON (like "jay son" and "Jason"). All considered, "Jay son" is apparently more canonical, with "Jace on" being a commonly-used and approved alternative, yet neither being official. Clears everything right up... :) (talk) 16:55, 12 February 2012 (UTC)

Differences between JSON and Javascript literals

Could it be worth to list in detail the differences between JSON syntax and the one of Javascript literals? The reason would be to explain how JSON is a subset of Javascript.

JSON syntax forces some notations (most notably strings delimited only by quotes, object property names which must be string and a smaller set of escape sequences) which may not be clear to people who know Javascript but didn't read the JSON specs carefully.

--Alessio (talk) 12:35, 2 July 2009 (UTC)

Yes, I agree such a section should be written down. I could write it if I have more time. Hope someone is more free than I am and could write it first :) 石庭豐 (talk) 21:04, 22 April 2011 (UTC)

Fragment regarding Efficiency moved from main page

"edit: While data compression is not covered in the standard, there is no reason one could not compress/decompress the entire response on both ends of the transmission. Also strings may be interned if needed by having an array structure, call it strings that contains all the strings to be interned, and then using the indexes into the array in place of the string. One must note though that string interning only makes sense with large documents, because while it lowers transmission time it also increases processing time. If responses are large it may be best to split the transaction into several shorter and more versatile requests."

—Preceding unsigned comment added by Balrog-kun (talkcontribs) 07:56, 20 September 2009

Efficiency versus Redundancy

JSON's lack of efficiency is not always a disadvantage. Lack of efficiency derives from the fact that most strings are not JSON encodings. But this implies that if a JSON string is corrupted it will almost certainly not parse - which is a good thing. Does anyone know of a statistical analysis showing the probability of being able to parse a corrupted JSON string? — Preceding unsigned comment added by (talk) 13:26, 22 November 2011 (UTC)

Better example?

The example at the top of the page only shows objects, arrays and strings. Could a better example please be put up showing a number, a boolean and a null? -- (talk) 22:58, 2 November 2009 (UTC)

Done. Things like that bother me as well. (talk) 20:32, 27 November 2009 (UTC)

Technical template

This article, as written, is quite effective in describing JSON to those you wish to use it. Most included technical details are relevant and contribute to the articles usefulness IMHO. Consequently, I removed the technical template. Roesser (talk) 21:44, 12 February 2010 (UTC)

Remove JSONP reference?

I don't believe that the JSONP reference belongs in this article. It doesn't follow from the subject being discussed and it sounds "shoehorned" into this article to be able to piggy back from it. This article, along with the info related to JSONP, would benefit if the part regarding JSONP was cut off this article and added into a new article. -- Mecanismo | Talk 09:36, 18 April 2010 (UTC)

I agree with this. I don't know how WP:NOTABLE JSONP is, but it is certainly not important enough to have all this space, and subsections of its own, in this main article. It is shoehorned into here too, and not very well: The JSON article is about an internationally agreed data format, no longer a detail of JavaScript. JSONP is only relevant in limited client-side JavaScript (probably Ajax) scenarios, yet it is not introduced in this way here, or given with any caveats at all in fact. I propose a new JSONP article, move all this stuff into it and mention it here as a 'See also' link. Does anybody have any objection to this plan? --Nigelj (talk) 19:24, 14 June 2010 (UTC)
Done. 22 March 2011. —Preceding unsigned comment added by (talk) 00:03, 23 March 2011 (UTC)

Does JSON define 'objects'?

I just removed a comment in <ref> tags from the lede that said that the 'objects' defined by JSON are not 'true' objects, because they only contain name-value pairs and no executable code. There is a strict sense in which this may be true, but there are various other 'readings' of the facts in which it is not.

First, in JavaScript, the executable part of a 'function' is defined as a 'value'. These values are exactly equivalent to any other values and can be stored in variables, arrays and objects, as well as being able to be invoked and executed (see JavaScript the definitive guide, Flanagan, P. 32). Therefore, a JSON string can indeed include executable functions, along with other data, and these can be invoked by a JavaScript interpreter later. This is the reason that there can be security issues to using eval() on untrustworthy JSON.

However, looking at we see a couple of examples of making use of this syntax. The first thing to note is that, because JavaScript is prototype-based, object-based language (rather than a class-based, object-oriented one like Java or C#) there is slightly more to assembling a prototype-based object correctly than might first occur to one.

Lastly, notice the comments in that discussion from the JSON Schema folk: Although all this may work in JavaScript, JSON Schema was meant to define a notation that could (and is) used by just about every programming language. Clearly, a function written in JavaScript cannot be run in another language.

So, I think we could have a short section on this in the article, but I don't think we can write it off in an uncited footnote buried in the lede. Does anybody else think it's worth covering properly? Or not at all? --Nigelj (talk) 17:29, 7 June 2010 (UTC)

Comparison with other formats

I'm not happy with most of this section. First, JSON is an "open standard designed for human-readable data interchange", second it has a media-type, an RFC and a wide use-base on the internet, particularly related to Ajax data, but other uses too. That makes it somewhat comparable to XML, which is often a realistic option when JSON is used for data interchange. But, recently some editors have taken the view that because JSON has historical links to a JavaScript language construct, then internal language structures from other languages and some proprietary file-formats are comparable too, and need comparing here. This is not so. Windows registry format could have been standardised and gained wide use on the internet for data transfer, but it did not. Nor did ini files, PHP array initialisers, MAC OSX property files, nor YAML. Nor are they likely to gain the user-base of JSON (or XML) any time soon, and even if they did, they have their own articles and need not be described in detail with large examples here. I feel that this whole section just dilutes the focus of this article on JSON with other might-have-beens that are not comparable. Many other languages now have JSON parsers available, the equivalent of JavaScript's eval(), so even the historical link with that language are irrelevant now. Can we prune this section right down, please? --Nigelj (talk) 20:20, 25 August 2010 (UTC)

Well, nobody had any comment to make for over 6 months here, so I have gone ahead and removed the irrelevant sections. The article is much clearer now. Considering the vast section on JSONP, and the still heavyweight comparisons with XML, I would say that still less than half of the article is actually about JSON, but it's a lot better than it was when maybe only 10% - 20% was about the main subject. --Nigelj (talk) 20:23, 14 March 2011 (UTC)

Data types, syntax and example

I fail to see why an XML example is given in this section, surely that is only relevant in the comparison section? The first of the two XML examples given is possibly the most ridiculously poor use of XML I've ever seen. The whole article reads like an attempt at balance is being made by giving equal space to two factions in a holy war. (talk) 20:48, 27 January 2011 (UTC)

Unique keys?

Is it required that the keys in an object are unique? Example:


If not: Do the common JSON libraries support the above example? A simple key lookup is not possible for that. --RokerHRO (talk) 18:24, 21 February 2011 (UTC)

I'm not sure how to understand your first question. By "keys", you actually meant "properties" (of objects) because we are using the language/jargon of JavaScript. For your second question, the simple answer is "yes" but maybe not as what you expected. Let me explain.
In order to interpret your data, we have to go back to the source of JSON: Javascript. Maybe you would like to consider the object structure as a collection in some language you're using or thinking about, but in order to make sure that JSON is "language neutral", we must also guarantee that the same data are read in all supported language (otherwise, that would mean JSON depended on one particular language to get a particular set of data)
Your data is essentially equivalent to
var a = {  // a is just a variable name which isn't important here, could have been b, c, whatever
So, at the end, you just have = 42 as the previous values were all replaced by successive assignments. And when I look at your data structure, I'm not sure it's very useable. What do you expect to get when you access the "foo" property (or key, as you like)? I mean, it's very common to see one-to-one collections or many-to-one collections, but I'm not sure one-to-many collections is manipulatable. 石庭豐 (talk) 10:02, 18 April 2011 (UTC)
Thanks for your answer.
Albeit JSON was invented with JavaScript syntax in mind, and being evaluable by JavaScript interpreters, JSON got a different formal syntax definition that differ in some aspects from JavaScript, i.e. JSON is much stricter and does not allow anything that JavaScript allows in its objects.
I read the RFC again and more carefully and it seems that JSON forbid our example. --RokerHRO (talk) 15:02, 21 April 2011 (UTC)
It's not correct to say "JSON got a different formal syntax definition" (which implies it could have something that JavaScript doesn't support). Better to say "JSON got a stricter formal syntax definition" as you've written later.
I haven't read RFC carefully, to be honest. So I'd like to know which part of it forbids your example because I don't think it's forbidden. For me, the example is completely syntactically correct but it just won't give result as you expected, as I've written. 石庭豐 (talk) 10:49, 22 April 2011 (UTC)
For me stricter is a kind of different. ;-) But I think the article can be better to emphasize the differences between JavaScript and JSON. --RokerHRO (talk) 11:24, 24 April 2011 (UTC)
Exact, but the other way round is not true (ie, different is NOT a kind of stricter). Think of this simple logical example:
A - There's this message "This room is reserved to every woman" written on a door
B - every woman is a kind of everyone
Can you change the message to "This room is reserved to everyone"?
The answer is "No, it's (logically) not correct to say/do so".
On the other topic, yes, the article should show the differences between both JavaScript and JSON. 石庭豐 (talk) 15:10, 27 April 2011 (UTC)

JSON is not a subset of JavaScript

As referenced at JSON is not actually a subset of javascript; there are some valid json strings that are not valid javascript code. I propose removing references to "JSON is a subset of javascript", though it might be worth mentioning this common misconception. I am not going to make this edit today but will later if it has not been done and there is no good reason not to. Thomblake (talk) 17:46, 16 May 2011 (UTC)

Damn! I think that is a specification bug. I assume the JSON guys were not completeley aware of all the Unicode pitfalls. :-( I hope it is fixed in the next JSON standard. --RokerHRO (talk) 13:44, 21 May 2011 (UTC)

File:Json-syntax-diagram-array.gif Nominated for speedy Deletion


An image used in this article, File:Json-syntax-diagram-array.gif, has been nominated for speedy deletion for the following reason: All Wikipedia files with unknown copyright status

What should I do?

Don't panic; you should have time to contest the deletion (although please review deletion guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page.

  • If the image is non-free then you may need to provide a fair use rationale
  • If the image isn't freely licensed and there is no fair use rationale, then it cannot be uploaded or used.
  • If the image has already been deleted you may want to try Deletion Review

This notification is provided by a Bot --CommonsNotificationBot (talk) 17:15, 5 September 2011 (UTC)

File:Json-syntax-diagram-number.gif Nominated for speedy Deletion


An image used in this article, File:Json-syntax-diagram-number.gif, has been nominated for speedy deletion for the following reason: All Wikipedia files with unknown copyright status

What should I do?

Don't panic; you should have time to contest the deletion (although please review deletion guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page.

  • If the image is non-free then you may need to provide a fair use rationale
  • If the image isn't freely licensed and there is no fair use rationale, then it cannot be uploaded or used.
  • If the image has already been deleted you may want to try Deletion Review

This notification is provided by a Bot --CommonsNotificationBot (talk) 17:15, 5 September 2011 (UTC)

File:Json-syntax-diagram-object.gif Nominated for speedy Deletion


An image used in this article, File:Json-syntax-diagram-object.gif, has been nominated for speedy deletion for the following reason: All Wikipedia files with unknown copyright status

What should I do?

Don't panic; you should have time to contest the deletion (although please review deletion guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page.

  • If the image is non-free then you may need to provide a fair use rationale
  • If the image isn't freely licensed and there is no fair use rationale, then it cannot be uploaded or used.
  • If the image has already been deleted you may want to try Deletion Review

This notification is provided by a Bot --CommonsNotificationBot (talk) 17:15, 5 September 2011 (UTC)

File:Json-syntax-diagram-string.gif Nominated for speedy Deletion


An image used in this article, File:Json-syntax-diagram-string.gif, has been nominated for speedy deletion for the following reason: All Wikipedia files with unknown copyright status

What should I do?

Don't panic; you should have time to contest the deletion (although please review deletion guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page.

  • If the image is non-free then you may need to provide a fair use rationale
  • If the image isn't freely licensed and there is no fair use rationale, then it cannot be uploaded or used.
  • If the image has already been deleted you may want to try Deletion Review

This notification is provided by a Bot --CommonsNotificationBot (talk) 17:16, 5 September 2011 (UTC)

File:Json-syntax-diagram-value.gif Nominated for speedy Deletion


An image used in this article, File:Json-syntax-diagram-value.gif, has been nominated for speedy deletion for the following reason: All Wikipedia files with unknown copyright status

What should I do?

Don't panic; you should have time to contest the deletion (although please review deletion guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page.

  • If the image is non-free then you may need to provide a fair use rationale
  • If the image isn't freely licensed and there is no fair use rationale, then it cannot be uploaded or used.
  • If the image has already been deleted you may want to try Deletion Review

This notification is provided by a Bot --CommonsNotificationBot (talk) 17:16, 5 September 2011 (UTC)

Eval, irrelevant citation?

In "Data types, syntax and example" section, it is asserted that "The contact variable must be wrapped in parentheses to avoid an ambiguity in JavaScript's syntax.[5]".

However, in the cited source (, the same text is asserted without any explanation. This kind of citation does not provide any usefulness to the mentioned assertion.

This assertion is also unfounded in QT documentation (

I have tried the example in Wikipedia JSON article in Firebug console and works fine with and without parentheses in eval. I am not stating that parentheses should be omitted, as there may be situations where they are needed, what I am objecting to is that the point is not justified by the given reference. (talk) 10:44, 28 September 2011 (UTC)

Quoting verbatim, the cited ref says, "The text must be wrapped in parens to avoid tripping on an ambiguity in JavaScript's syntax." I think that's pretty close to what we say. Note that neither the ref nor this article is saying that the parentheses are needed in JSON, but that they are needed in JavaScript if JSON is to be evaluated directly by a JavaScript interpreter using eval(), which is not recommended anyway. It does not say that there is a bug in any particular JavaScript interpreter, but in the defined syntax of the JavaScript language itself. Therefore, it may work in some actual implementations, and not in others, depending how the designers of each interpreter have read the definition of the language syntax when coding their product. That's why it's best to rely on well-informed scholarly references, rather than personal experiments in particular cases, or WP:OR as we call that here on Wikipedia. Thanks for your interest. --Nigelj (talk) 21:55, 28 September 2011 (UTC)

Section 9.1 - XML - no citations needed

No citation is needed for the statement that XML is more verbose than JSON since XML includes closing tags that JSON does not. The statement is self evident in its own language, from the link to the article on XML, and from the example in the XML section and the first JSON example in the article. The assertion is not the subject of scholarly research and is verifiable on its face.

No citation is needed in stating that a typical repeating data compression algorithm will produce output probably not be much longer using XML than JSON data since that is what compression programs do - identify and abbreviate the representation and placement of repeating components such as XML tags. Rather than cite, a link to the article "data compression" from the word "compression" would be more appropriate for those with no familiarity with data compression. — Preceding unsigned comment added by (talk) 21:59, 27 December 2011 (UTC)

Longer or shorter than XML?!

I don't want people to get fiercely competitive over this point in the article, and recently reverted some comments that were starting to accrue. Mind you, in the interests of completeness, I thought I'd share my WP:OR here before I closed the files without saving.

First, it is true that that the JSON example given in the article is 234 characters without whitespace, and the short-form (attribute-driven) XML example there is 254 characters without whitespace. But, they are not equivalent. First, the overall object is named "person" in the XML but is anonymous in the JSON. Second, each of the objects in the JSON phoneNumber array is also anonymous, but is named phoneNumber in the XML. Thirdly, the equivalent collection in the XML is named phoneNumbers, which is also one character longer. For the purpose of demonstrating equivalence, the following are more fairly compared:

    "person": {
        "firstName": "John",
        "lastName": "Smith",
        "age": 25,
        "address": {
            "streetAddress": "21 2nd Street",
            "city": "New York",
            "state": "NY",
            "postalCode": "10021"
        "phoneNumber": [
                "type": "home",
                "number": "212 555-1234"
                "type": "fax",
                "number": "646 555-4567"
<person firstName="John" lastName="Smith" age="25">
  <address streetAddress="21 2nd Street" city="New York" state="NY" postalCode="10021"/>
     <number type="home" number="212 555-1234"/>
     <number type="fax" number="646 555-4567"/>

Here the JSON has 245 non-whitespace characters, and the XML has 230. In the following example, I managed to get the XML down to 228 characters with no loss of information.

<person firstName="John" lastName="Smith" age="25">
  <address streetAddress="21 2nd Street" city="New York" state="NY" postalCode="10021"/>
     <number type="home">212 555-1234</number>
     <number type="fax">646 555-4567</number>

However, I did not put any of these into the article as I don't think the point of the section is to have a "mine is better than yours" abridgement competition. --Nigelj (talk) 15:09, 14 December 2012 (UTC)

Zip Code a number ?

In the code example on the page zipcode is treated as a number which is not correct. 00023 can be a zipcode 07078 is a zipcode but the former would be read as 23 and the later as 7078. Age is treated as a number which is correct. If there was a social security number, despite its name, it is not a number but an identifier since nobody needs to add 2 zipcodes or 2 social security numbers. Thanks Meishern (talk) 18:23, 22 January 2013 (UTC)

Too much information?

In these two edits, added a lot of unreferenced detail about State Software Inc. I don't think we need all that. It may be of interest in some geeky way, but what basis do we have to believe that it's all true? Is any of it notable (WP:UNDUE)? --Nigelj (talk) 21:51, 31 January 2013 (UTC)

Uninformative Reference

The article states that the parentheses are needed inside the eval function because of Javascript syntax issues, and links to the paper by Crockford describing JSON, in which he makes the same statement. But Crockford does not elaborate, and his claim about the need to do it is therefore not substantiated, and parroting it here doesn't shed any light on what the syntax problem is. — Preceding unsigned comment added by (talk) 02:48, 6 February 2013 (UTC)

JSON pronunciation

So, I wonder, where does it come from? That's not the only way people can pronounce JSON. (talk) 11:41, 19 May 2013 (UTC)

Document Markup Languages template removal

I've removed the Document Markup Languages template (and JSON from the template), as, according to, JSON is not a Document Markup Language. If anyone has an issue with that, I'd be happy to discuss it. Mount Flatten (talk) —Preceding undated comment added 08:43, 28 May 2013 (UTC) (Edited by Mount Flatten (talk) 08:48, 28 May 2013 (UTC))

JSON example validation

Has anyone actually tried to parse this with JSON.parse? I tried it with Mozilla Firefox 18.0.02 on Ubuntu, and it gives me "unexpected character". Miller9904 (talk) 07:17, 16 June 2013 (UTC)

Shameless Plug?

Anyone else notice the shameless plug for Jayrock? — Preceding unsigned comment added by (talk) 14:43, 24 October 2013 (UTC)

Geek Speak

This article may be informative to a programmer or techie, but I suspect that someone able to understand it probably already knows a lot about the topic. It would be helpful if the first graf or two could give a quick understanding of what json is and how it works, for the layman. I see "json" at the end of files that I can't open. I just wanted to know what it is and what it does (and why I can't open it, but that's not really your problem). Thanks. Katetx5 (talk) 16:43, 11 November 2013 (UTC)Kate Nov 11, 2013

No- level is fine- this is a new topic to me, but I do code, not on Javascript and it gave me sufficient information in a efficient way. To open the file to view- use gedit or any text editor - I believe Bill Gates puts a program called Notepad in his distros.

-- Clem Rutter (talk) 11:08, 26 March 2014 (UTC)

JSON Schema, need some historical relation with Rx or Kwalify?

Remembering here that I have removed, from article's text, the Kwalify citation... But perhaps have some historical relation with Rx or Kwalify. It is not evident for me; is only incidental: see --Krauss (talk) 11:30, 24 July 2014 (UTC)

Why the string key limitation?

Does anyone have any information on why JSON limits the keys of the object (associative array) type to just strings? This immediately mangles many good representions of data. (For example, representing the pieces on a chess board as a mapping from [rank, column] -> [piece, color].) This seems quite odd coming at it from, for example, a Clojure/EDN perspective. Is this a hang-over from the JavaScript origin of JSON; does JavaScript have this limitation? Was it a deliberate design decision to keep things 'simple' (by some definition of simple)? (talk) 15:07, 20 February 2015 (UTC)

Yes, JavaScript has this limitation. In JS, the keys can be written without quotes if they conform to the rules for naming identifiers. You can also use plain numbers as keys. But this is just syntactic sugar: the keys foo and 42 are equivalent to "foo" and "42" respectively. JSON makes the grammar more regular by explicitly requesting the keys to be written as strings. —Edgar.bonet (talk) 17:12, 20 February 2015 (UTC)

Remove notes about undefined

I suggest to remove the note about handling of 'undefined' starting with the following:

"For some reason undefined was left out as a supported data type (and one finds suggestions that null be used instead.) In JavaScript {a: undefined} often behaves the same as {}. Both translate as "{}" in JSON. However undefined as an explicit property value does have use in JavaScript inheritance situations such as: ..."

First of all, "for some reason" is not very encyclopedic, and JavaScript inheritance is not relevant to JSON data transfer format. Also, the note provides specific code samples which are not relevant to the article, and suggest bad coding practices (replacing `undefined` with string "UNDEFINED"):

"Converting this JSON back into JavaScript is not as straight forward. While JSON.parse can take an optional reviver argument which is essentially the inverse of a replacer, it can't be used in this situation - if that function returns undefined the JSON.parse logic will understand this to mean not to define a property rather than defining one with a undefined value. Instead one has to explicitly post process the result from JSON.parse replacing each "UNDEFINED" with undefined."

Alternatively, the mention about 'undefined' not being allowed could be included in the article, but I don't think it justifies a separate section.

AdamByrtek (talk) 15:57, 11 June 2015 (UTC)

Why undo info on history?

"Many languages have associative arrays" is totally beside the point! Perl was probably the 2nd mainstream language after Lisp to introduce them, and most probably the 1st to make them part of the syntax, instead of needing some cludgy library. And it is exactly this {hash syntax} (with one changed operator, ':' instead of '=>') and Perl's [array syntax] that JavaScript and hence JSON copied. This is definitely worth a mention. — Preceding unsigned comment added by (talk) 22:49, 18 August 2015 (UTC)

If you have a good reference to back this claim, this may be suitable for the article Associative array. JSON, however, did not borrow this notion from Perl: it borrowed it from JavaScrip, which was influenced by many languages, some of which may have in turn been influenced by Perl. The connection between Perl and JSON is so distant that comparing their syntaxes is pointless. —Edgar.bonet (talk) 19:13, 19 August 2015 (UTC)

Back then Perl was the web-language, albeit server-side — still the closest thing to where JavaScript was going. Brendan's Perl inspiration is so obvious: /Regexps/ as part of the syntax were already in Perl4. Many other things (anonymous subroutines, closures, objects of the same class with varying attributes) that JavaScript followed closely, were introduced in 1994 with Perl5 and openly discussed since 93. All that is beside the point here, but I found that under 2. & 3. shows the [array, ...] and {hash => syntax, ...} that Perl5 introduced. Replace undef with a Java inspired null, and '=>' with an SMTP/HTTP-header inspired ':' and you have JSON's spitting image. — Preceding unsigned comment added by (talk) 14:09, 22 August 2015 (UTC)

The history of JavaScript as a Web language is irrelevant, as most of what you wrote in your last answer, which looks very much like original research, not acceptable in Wikipedia.
In your edit of the article, you wrote “[JavaScript] takes its data structure syntax from Perl [...]”. Assuming you are right, you first have to provide an appropriate reference, then you have to search for the proper place to add this information. The opening paragraphs of this article is not the proper place. Especially the sentence that you edited, which is about an unrelated idea. Then you wrote that the `:' was inspired by RFC 822. Although it sounds plausible, this also would need to be backed by a reference. —Edgar.bonet (talk) 10:00, 24 August 2015 (UTC)

Removing absurd section on efficiency

The current section on JSON's efficiency is silly, and isn't based on any relevant piece of information. Basically, it tries to claim that the use of "textual data formats" limit the efficiency with the following silly claim:

The thing is, this applies to every single grammar which is parsed by a computer. Symbols are extracted from data streams by analyzing each and every single unit of information individually, whether they represent characters or not, which means that this criticism boils down to "JSON's efficiency is limited because it needs to be parsed". This is an absurd statement.

Then, it proceeds to claim that the absence of any explicit support for data compression limits the language's efficiency. This statement not only contradicts the previous statement, as employing a data compression scheme would increase the computational requirements, but it is also absurd as it is quite possible to implement data compression in a higher abstraction level.

Therefore, as this whole section amounts to pure drivel, I will remove it from the article. -- Mecanismo | Talk

You are not wrong, except maybe for, what the writer of the seems to have meant, JSON is not a binary format. E.g. you have to parse numbers, and they take more space (the big ones..) than say storing a 64-bit floating point number in binary. That also has problems.. like endianness, and is probably not faster as a distribution format. BSON does this and PostgreSQL has both a JSON and binary variant of if (not BSON), mostly to help with indexing (and storage space). comp.arch (talk) 09:36, 28 August 2015 (UTC)

Comparison with CSON

About this edit. I may not disagree.. I originally found CSON for Coffescript SON (CSON). I've seen it used by Coffeescript code, and Coffeescript isn't exactly obscure (most common/first varian that compiled to JavaScript?). Yes, my info wasn't about that. Maybe that needs to be added. And if done, then would be confusing for the other CSON.. Then I think, mentioning both, might be in order.. Not sure if it is helpful to mention name and not say much about it, but I also didn't want to take up too much space. The YAML, roundtrip functionality, seemed also interesting. comp.arch (talk) 09:30, 28 August 2015 (UTC)

I think if the format is notable enough, a first step would be for it to have its own article (with an appropriate disambiguation warning) and/or to be listed in Comparison of data serialization formats. —Edgar.bonet (talk) 14:04, 28 August 2015 (UTC)
HOCON is not there, while it has its own WP page.. Not sure what I should read into very few results for googling it: "HOCON" and much more with "YAML". I wander if it is on the way out. This article doesn't need to take sides(? or should it drop HOCON?), but I thought YAML was the preferred readable superset version? comp.arch (talk) 11:27, 30 August 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on JSON. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.—cyberbot IITalk to my owner:Online 13:26, 10 January 2016 (UTC)

mentioning jq within Samples section

I mentioned jq within the Samples section, because that's where DOM, XPath, and XSLT get mentioned together with XML. Of course mentioning jq can very well happen in a more appropriate place. --johayek (talk) 14:22, 27 February 2016 (UTC)

this system is also owned by 3DO

This sentence appears in the History section, but there is no other mention of 3DO in the article, nor explanation of what or who 3DO is. (talk) 15:04, 12 May 2016 (UTC)