Is JSON better than XML?

Use JSON, not XML. You hear it all the time these days. JSON is so much better. It must be because everyone is saying it, right? I’m starting to think not.

Fellow Yahoo Douglas Crockford, creator/inventor/founder/father of JSON, says that JSON is better than XML. He says it whenever he can (most recently in his post Does XML have a future on the web?). It is, of course, natural that he would say that JSON is better than XML; every parent thinks their kid is adorable and quite possibly the smartest kid ever. I’m just not sure his hypothesis is based in fact.

What really makes one data interchange format better than the other? As long as it serves the needs of the developers using it, then the format can at least be said to be adequate. The primary usage of JSON is for data delivery between browsers and servers. Even though it can technically be stored in files and the like, JSON is rarely used outside of the web environment. XML can also be used for data delivery between browsers and servers but also is stored in files and used to extract data from database. For this comparision, I’ll just consider the browser/server usage.

Syntax: JSON syntax is quite light and definitely less verbose than XML, with all of its start and end tags. When it comes down to pure byte-size, JSON can represent the same data as XML using fewer characters.

Weight: Since JSON syntax requires fewer characters, it is lighter on the wire than XML. The question is if this really matters. Any large data set is going to be large regardless of the data format you use. Add to that the fact that most servers gzip or otherwise compress content before sending it out, the difference between gzipped JSON and gzipped XML isn’t nearly as drastic as the difference between standard JSON and XML.

Browser Parsing: On the browser, there’s no such thing as a JSON parser. However, there is eval(), which interprets JavaScript code and returns the result. Since JSON syntax is a subset of JavaScript syntax, a JSON string can be evaluated using eval() and quickly turned into an object that is easy to work with and manipulate. XML parsing on the browser is spotty at best. Each browser implements some different way of dealing with XML and none of them are terribly efficient. In the end, the XML ends up as a DOM document that must be navigated to retrieve data. Native JavaScript objects are much easier to work with in JavaScript than DOM documents, although the playing field would level out considerably if every browser supported ECMAScript for XML (E4X), which makes working with XML data as easy as working with JavaScript objects.

Server Parsing: On the server, parsing is just about equal between JSON and XML. Most server-side frameworks have XML parsing capabilities and many now are starting to add JSON parsing capabilities as well. On the server, these parsers are essentially equal, parsing a text format into an object model. JSON holds no advantage over XML in this realm.

Querying: This is where XML really shines. Using XPath, it’s possible to get direct access to a part of multiple parts of an XML data structure; no such interface exists for JSON. To get data from a JSON structure, you must know exactly where it is or else iterate over everything until you find it.

Format Changes: So you have your data in one format but you want it in another. If the data is in XML, you can write an XSLT template and run it over the XML to output the data into another format: HTML, SVG, plain text, comma-delimited, even JSON. XSLT support in browsers is pretty good, even offering JavaScript-level access to it. XSLT support on the server is excellent. When you have data in JSON, it’s pretty much stuck there. There’s no easy way to change it into another data format. Of course it’s possible to walk the structure and do with it as you please, but the built-in support isn’t there as it is with XSLT for XML.

Security: Since the only way to parse JSON into JavaScript objects is to use eval(), it opens up a huge security hole. The eval() function will execute any arbitrary JavaScript code and so is dangerous to use in production systems. Invalid JSON that contains valid JavaScript code could execute and wreak havoc on an application. The solution, of course, is to build a true JSON parser for browsers, but we’re not there yet. On the other hand, XML data is completely safe. There is never a possibility that parsing XML data will result in code being executed.

With all of this considered, the two main advantages that JSON has over XML are 1) the speed and ease with which it’s parsed and 2) the ease of simple data retrieval from JavaScript object. Note that both of these advantages exist on the browser side of things; on the server-side they are essentially equal, unless you take querying and format changes into account, in which case XML is the clear winner. I don’t think that code size really is an advantage when you’re talking about gzipped data. I also believe that if ECMAScript for XML is implemented in all browsers, that JSON’s advantages go away.

So what do you think? Is JSON better than XML?


  1. David Golightly

    So essentially your argument for XML over JSON is: XML has more established infrastructural support, therefore it's a better data format. All of the advantages you cite are boiled down to the work of the w3c, Sun, Microsoft, and the myriad other standards bodies and code shops throwing their weight behind this format. It's nothing inherent in XML over JSON; we could just as easily implement the DOM/XPath/XSLT/etc. for JSON as for XML; look eg. at JSON/T, JSONPath, Jaql, JsonML, etc. It's just getting the makers of Java, MySQL and the .NET framework to provide the same bells & whistles for JSON as they do for XML. Which we're beginning to see. And then getting web service and feed API providers to provide a JSON alternative.

    But when you remove the (rather tangential) support question, and compare the two formats on pure merit (concision, expressiveness, simplicity of syntax, and human readability), I don't see any merit that XML has over JSON.

  2. Wally

    Good post.

    I don't think either is better than the other. Within the browser, in JavaScript, I prefer a JSON response, because not every (grade-A) browser has a native XML parser. For me, that's the best reason to use JSON. Otherwise, I prefer XML. Like you said, there's XPath and XSLT and there's plenty of XML editors that JSON does not (that I know of).

    Another factor to consider is that most frameworks (Rails, Symfony) have evolved so well that passing a parameter to, for example, a RESTful service can return XML, JSON, RSS, or a serialized obj. You can dip your feet, run some tests and determine if you need to change communication means.

    In the end, whatever fits best for your webapp, wherever you may need that data.

  3. daaku

    I think for the case you mention (or any case where we need to deal with a browser) - JSON wins most of the time. But as soon as you want *a lot* of data in your browser, the native XML parsing and XPath querying will give huge speed boosts. This can obviously be fixed, but as it stands right now, large amounts of JSON is a pain to work with since a javascript loop to find some specific object is way slower than an XPath query. [That being said, unless you're using something like Sarissa, cross-browser XPath is still a PITA.]

    I think in the long run, JSON and XML are not really competing. JSON is and will remain a very convenient format, especially for browsers, and for anything in general.

    For static files I write by hand (conf files and such), I like YAML, specifically for its built in aliasing and simple inheritance support.

    XML is more powerful/feature-full/bloated, and sometimes a better choice - I can't see myself writing JSON for a Widget (Y! Widget, Dashboard...) or a Flex app - XML does seem like a better fit there.

    In my head, JSON is data serialization, and XML is application markup.

    [btw, your email regex on form submit does not allow a dash, at least before the @]

  4. Nicholas C. Zakas

    @David - My point isn't that XML is better than JSON, it's that JSON isn't better than XML. My overall point is that the perceived advantage that JSON has over XML could easily disappear. XML is a lot closer to doing everything we need it to do than JSON is. As you point out, this is thanks to work from a number of groups. All of the JSON utilities you mention are a start, but they're not standards, they're not already available in browsers, and therefore are not really factoring into this debate.

    @Wally - I think you hit it right on the head: use whatever works best for you. Don't get backed into a corner because someone says something is "better."

    @daaku - You're using JSON and XML in very specific ways; just keep in mind that they aren't the only ways and that they are, indeed, competing for data transfer over the Web. And I'll check my email regex, thanks for the heads up.

  5. Jimmy

    Thank you very much for the post. I have been wondering about this myself. Especially, if there were any JSON feature that is equivalent to XPath feature as I use XPath a lot.

  6. Julien Lecomte

    "Using XPath, it's possible to get direct access to a part of multiple parts of an XML data structure; no such interface exists for JSON."

    This is untrue. See


  7. Julien Lecomte

    "There is never a possibility that parsing XML data will result in code being executed."

    Never say never, especially when it comes to security on the web.

  8. Nicholas C. Zakas

    @Julien - I say never until someone proves me otherwise. :) I have yet to hear of code getting executed downloading XML from a server.

    As for JSONPath, we're still talking non-native, non-standard support for something. People come up with interesting ways of representing and manipulating data all the time, but if it requires yet another code download, I don't consider it on par with native solutions.

  9. Isaac Z. Schlueter

    Re: XPath
    XPath is clever, surely. But I've never found myself wanting for it when dealing with a JSON object. OTOH, SimpleXML is so refreshing to use precisely because it translates a bunch of XML into something like a native data object.

    Note that XPath, while being a standard that relates to the handling of XML-encoded data, is not a feature of XML, but rather of the specific language environment. Giving XML credit for XPath is like saying "Strings are great, because you can use regexes on them." Well, sure, regexes are nice, but it's the *environment* that provides regexes, not the *string*.

    There's no reason why Javascript or PHP couldn't implement xpath (or something suitably xpathy) for nested data structures other than XML strings. The lack of a standard is most likely temporary.

    Re: Browser Parsing
    There are ways around the security issues today, and browser makers have heard the word and are building proper JSON parsers.

    Re: Server Parsing
    Parsing JSON will probably *always* be faster and less ambiguous than XML, simply because it is a serialization technique that more closely resembles the structure of the data it represents.

    What I think you miss in your discussion here is the fundamental difference in expression that JSON and XML aim at.

    Objective: give structured semantics to textual data.
    Order matters.
    Data types are inherited from SGML documents: Element, attribute, text, and comment.
    Semantics of "attribute" vs. "node" are usually unclear.

    Objective: Serialize a data structure in an architecture-independent format.
    Order doesn't matter, except for arrays.
    Data types are inherited from programming paradigms: number, string, hash, array, null, boolean.

    Using JSON to pass data between languages and programs means that the logic in each can be more easily kept in sync---the PHP program works on roughly the same data object that the Javascript program works on. Not so with XML. Hell, even within *one* language, there are often many different ways to work with XML.

    The big win for XML to be used in production today is that, because of the existence of a very standardized schema format and publicly available validators, it's very easy to create automated tests for data services that return XML. Of course, <a href="">there are proposals out there</a>, and it still doesn't make enough of a difference in the browser.

    Re: Size
    It's not only networks that care about wasted bytes. JSON with sane white-space and tabbing is a lot clearer than XML because it has less conceptual overhead. You know what the data object will be, because the code looks like it.

  10. Michael Galpin

    Your note on security and eval is not true. You mentioned Doug Crockford, well his json2.js lib is used as part of the YUI library JSON parser that provides security on top of parsing:

  11. Nicholas C. Zakas

    @Michael - I'm well aware of what's in YUI as I'm part of the team. My point about eval() is that it is not safe to use alone. Yes, there are scrubbers and regex's that help to make it safe, but on its own it's dangerous.

  12. Rob Mech

    I love reading pros/cons to each technology and then watching people debate it. I always say the same thing.

    There is no good or bad technology, only good technology used poorly.

    Right Tool, Right Job folks.

  13. chris thatcher

    I think in general the json/xml debate is a butter battle that is only a flicker in the python/java war. Xml does suffer from a long history of over-verbosenss, primary due to the under use of attributes for simple types, redundant nesting that really adds no additional structure to a document. Json on the other hand has no notion of namespace and so couldn't really be used to support a specification like Atom as easily as xml does. It's painful for me to hear people arguing strongly for the banishment of either and it clearly indicates a prejudice or lack of technical knowledge and/or experience.

Understanding JavaScript Promises E-book Cover

Demystify JavaScript promises with the e-book that explains not just concepts, but also real-world uses of promises.

Download the Free E-book!

The community edition of Understanding JavaScript Promises is a free download that arrives in minutes.