Thursday, January 4th, 2007

JSON vs. XML: The Debate

Category: Editorial

The big debate over the winter holidays seems to be people shouting about JSON vs. XML.

Dare Obasanjo has a nice round-up, as well as his own opinions on the matter:

In the past two weeks, I’ve seen three different posts from various XML heavy hitters committing this very sin

  1. JSON and XML by Tim Bray – This kicked it off and starts off by firing some easily refutable allegations about the extensibility and unicode capabilities of JSON as a general data transfer format.
  2. Tim Bray on JSON and XML by Don Box – Refutes the allegations by Tim Bray above but still misses the point.
  3. All markup ends up looking like XML by David Megginson – argues that XML is just like JSON except with the former we use angle brackets and in the latter we use curly braces + square brackets. Thus they are “Turing” equivalent. Academically interesting but not terribly useful information if you are a Web developer trying to get things done.

This is my plea to you, if you are an XML guru and you aren’t sure why JSON seems to have come out of nowhere to threaten your precious XML, go read JSON vs. XML: Browser Security Model and JSON vs. XML: Browser Programming Models then let’s have the discussion.

If you’re too busy to read them, here’s the executive summary. JSON is a better fit for Web services that power Web mashups and AJAX widgets due to the fact that it is essentially serialized Javascript objects which makes it fit better client side scripting which is primarily done in Javascript. That’s it. XML will never fit the bill as well for these scenarios without changes to the existing browser ecosystem which I doubt are forthcoming anytime soon.

Next up: CSV vs. Fixed Width Documents.

Update: Dare’s round-up missed the real instigator of the JSON vs. XML meme: Dave Winer’s blog (here and here). Fun quotes, like this one from Dave:

As Dr Phil asks — What were they thinking?

No doubt I can write a routine to parse this, but look at how deep they went to re-invent, XML itself wasn’t good enough for them, for some reason (I’d love to hear the reason). Who did this [JSON] travesty? Let’s find a tree and string them up. Now.

And Douglas Crockford’s (JSON guy) reply:

I liked the part where Dr Phil said “What were they thinking?” I asked the same question when I first saw XML being proposed as a data format. There were obviously better alternatives.

The good thing about reinventing the wheel is that you can get a round one.

Don’t miss the two different comment threads as well, here and here. Fun times ahead as web service and Web Service APIs continue to collide. – Ben

Posted by Dion Almaer at 9:04 am

4 rating from 85 votes


Comments feed TrackBack URI

I believe that the most important thing to understand in the JSON and XML debate is that they are really fundamentally built for two distinct purposes. XML is built for giving semantic meaning two text within documents. JSON is built for data structures. Unfortuneately, most developers have not understood this, and just used whatever that felt was the most popular. Yes, XML can describe data structures, but when you start really looking at the syntax for describing simple things like empty arrays in XML, it should be obvious to people, that JSON is much more naturally built for data structures. Still the popularity of XML has forced it way into describing vast of amount of data structures. On the other hand providing semantic meaning to the text within documents is what XML excels at, HTML being the prime example. JSON actually does not fit this bill at all. Doing something like:
some important word
should not attempted to be done by JSON. Anyway, I wrote up an article myself that you can read on this issue:
I believe that the character set issues are really side issues compared to actual structural makeup of the two standards.
Another issue with JSON and XML is that I believe is going to become increasingly important is the ability to describe data with multiple references to single objects (closely related to turing completeness, I believe). Neither JSON or XML have native ability to handle this. You can go to for a description of an extension to JSON to handle this for more complete/correct data structure describality.

Comment by Kris Zyp — January 4, 2007

It seems the trackback did not work – I also wrote a great summary at

Unicode IS important, but I rarely worried about it except to escape some characters or CDATA sections.
JSON is NOT ‘XML reloaded’ – it serves a different purpose. There is a place for XML and lost of great tools. JSON may be newer, but it serves the client side much better

Comment by JSON — January 4, 2007

XML has no standard way of representing arrays, nor does it have a standard way of representing a map. Such things are represented by different conventions in XML, and as result, different XML applications will invarialy disagree about the format of such arrays and maps. There is no possibility of disagreeing about the format of arrays and maps in JSON because it is explicitly there in the specification. Not to mention the attribute versus child node representation problems in XML that are simply not present in JSON.

Comment by Json Is Better Than XML — January 4, 2007

Isn’t the “JSON vs XML” debate a bit like a “PNG vs JPG” debate, in which developers of image-display applications decide their apps will handle one or the other?

In a services-oriented world, once you’re past same-site restrictions (via signed scripts or trusted zones), you will have occasion to consume services providing SOAP, POX and JSON data, based on the service-providers preference regardless of your’s. Sure, if you control the service side, JSON can be much more efficient; but existing Web services won’t add this to their APIs just to make your life easier.

IMHO, the smart path is implementing a framework that can handle various data formats, via various retrieval methods (SOAP, REST, HTTP-POST, etc.) — possibly marshalling everything to JSON for faster processing.

Comment by ARWolff — January 4, 2007

There’s also a memory management angle. XML docs are managed natively in memory where as loads of interpreted javascript objects as globals tend to bog down the browser after a while. The folks in TIBCO’s General Interface (TIBCO GI) group handled this by persisting all data as XML, but providing a javascript API to get and set elements within those XML docs as Javascript objects and thus provide a bridge to JSON with the benefits of the native handling of XML in browsers. Of course the GI stuff is engineered for Ajax RIA solutions that are more like software and less like Ajax enhancements to HTML pages where the short life of such pages the issues of memory management may not arise as quickly as they would for full application GUI style Ajax applictions that look and feel like software.

FWIW–GI’s common data format handles that “difference between nodes and attributes” by defining an XML schema for the data that the GUI objects display that’s more aligned with JSON’s (beneficial) simplicity.


Comment by Kevin Hakman — January 4, 2007

I don’t see what benefit I get from using XML. JSON is more compact and seems to do everything I need. I’m using My-Bic, which is a loose kind of framework for Ajax, passing data to php methods and then getting it back and altering my web pages accordingly. My perception of XML, which may not be accurate, is that it incurs more overhead and doesn’t work as transparently.

In any case, both of them use xmlhttprequest, so technically even JSON is xml, isn’t it? I mean, in the form of one big xml object which you crack open to interpret the innards using JSON? If I’m wrong about that, well, that’s what I get for using other people’s tools and not really trying to understand how they work because they just work.

Comment by Dale — January 4, 2007

It comes to a question of how you’re using it. (With current browser tech) JSON works better if you need to dissect the response and look at individual pieces. XML works better if all you want to do is format and display the data (although cross-browser transforms take lots of tweaking). While JSON seems easier right now, my vote is actually for XML. With the XML/XSLT combo you can move processing up or down the application tier chain and reasonably expect the same results. I.E. a response processed and transformed by the middle tier can reasonably be expected to have the same results as a transform applied in client Javascript. For this to gel completely the browser builders must agree to a solid, standard object model for processing, parsing, and transforming XML in javascript. Or alternately build JSON parsers natively into the various middle tier languages.

Comment by Chris Cole — January 4, 2007

The point of XML is that you can describe vocabularies that describe data. Comparing JSON with XML is meaningless. If you want to compare JSON to anything, compare it to a XML vocabulary that was created to describe an object graph, for example WDDX or Plist, not XML as such.

Comment by Theo — January 4, 2007

The main difference is arrays…. xml does not support arrays, it possible to do someting like , but it is not standart, JSON support arrays {“clients”:[“client”:””]}. Also JSON is more elegant and compact.

Comment by Paulo Falcao — January 4, 2007

KevinH, thats a great point I’ve never heard stated before! I never thought about the difference between maintaining a large database of information in memory as JavaScript objects versus an XML document. Above a certain threshold, do you maintain your dataset as an XML DOM in memory? What kinds of numbers did you find in terms of benchmarking? I’d love to know how large the data set could get and how operations (put, get, etc.) were affected on that XML dataset as it grew. They great thing about XML is you can use client-side XSLT to do some nifty things for performance of large datasets as well, which is what I did on the HyperScope project to implement Engelbart’s addressing types, which were too slow with DOM-style operations.

Brad Neuberg

Comment by Brad Neuberg — January 4, 2007

You should use XML as common standard for a public API. An XML document is comprehensible for everyone who knows HTML or a markup language. So it’s more intuitive to understand and to read if the content is not beatified by an application. In this case JSON is just the JavaScript representation of XML data you need to e.g. show an RSS feed on your website. Although it’s useful to provide a JSON version to support the majority of web developers using Ajax (see the J ->JavaScript).
Fazit: JSON is more useful and less bureaucratic for web developers. I prefer it and I think that most Ajaxians prefer it for not cross-domain requests and for interfaces which are especially used in web services.

Comment by Andi — January 5, 2007

JSON is for Javascript, XML is for everything else. I don’t see whats there to debate. -.- Of course you can debate, but only if you are too lazy to add a two-way data output to your app. In that case you should stick with XML. I like both, but i use them on purpose instead of pursuing generalisation like XYZ > all.

Comment by Kjell — January 5, 2007

Both JSON and XML can be represented as an data structure of a serialized object.

XML is slow because we need to use XMLDOM to parse the retured string and convert it to an XML Object.

JSON is faster in many cases since all we need is to “eval()” the returned value.

Some limitations of JSON I knew can be listed below:
1.eval( ‘(‘ + jsonString + ‘)’ ); is slow, especially when jsonString is really a long string and it will be much slower in IE to evaluate it.

2.all JSON string should be JSON-Encoded.
For example:


Should be encoded as:


this really hurt the performance of your javascript if the incoming string is simply a chunk of HTML tags which have so many backslash and double-quotes.

I would say that mixing JSON with XML may be a solution for this.
For example:

{..JSON string…..}


Comment by Hedger Wang — January 5, 2007

Those who are interested in JSON for configuration files might also want to check out SweetXML. It is an alternate syntax for XML, much easier to read, which works as a drop-in replacement for XML.

Comment by Paul — January 7, 2007

I certainly agree with Kevin on this one. Aside from performance, there are other advantages of maintaining your JavaScript state in XML – which is something that the Nitobi framework enables. It makes sense to use XML when using a scripting language that is, for the most part, interacting with an XML based markup like HTML. Transforming the XML to another markup like HTML using XSLT on either the client and server is exceedingly simple. Not only is this easier than building an HTML string with JavaScript (don’t get me started on JSON based templating!) but it also has performance gains.

Comment by Dave Johnson — January 7, 2007

I agree that JSON and XML have different uses. If you want to shared data between a browser (client-side) and your server-side code JSON is great. JSON is compact, serializes and de-serializes to your native data types.

XML, in my opinion, are great for configuration files, markup data formatting, and data transforming. Example if you store meaning content like chapters and pages in a book structure and you need to output to web, print, PDFs, etc. XML would be the best choice. I would much rather look through and edit long XML documents by hand then a long JSON document.

Buddy from My Design Buddy

Comment by Buddy Toups — February 5, 2007

thx for article

Comment by praca za granicÄ… — May 18, 2007

I certainly agree with Kevin on this one.

Comment by filmy — May 29, 2007

thx for nice article, great work

Comment by teledyski — June 2, 2007

In that case you should stick with XML. I like both, but i use them on purpose instead of pursuing generalisation like XYZ > all.

Comment by życzenia — June 20, 2007


Comment by Kabarety — June 30, 2007

I’m a blogger-beginner. I’m happy about your article. Thanks

Comment by Gify — July 1, 2007

I think these blog is really useful for new comers and Excellent resource list.

Comment by Martino — July 2, 2007

It makes sense to use XML when using a scripting language that is, for the most part, interacting with an XML based markup like HTML.

Comment by kody — July 5, 2007

That was very good article, i think it was one of the best about XML.

Comment by Gta — August 18, 2007

It’s very intresting blog, and this article is briliant. It’s very usefull for everyone who uses XML.

Comment by Xam — August 19, 2007

All markup ends up looking like XML by David Megginson – argues that XML is just like JSON except with the former we use angle brackets and in the latter we use curly braces + square brackets. Thus they are “Turing” equivalent. Academically interesting but not terribly useful information if you are a Web developer trying to get things done.

…this is it!

Comment by voltaren — September 23, 2007

I’m a blogger-beginner. I’m happy about your article. Thanks

Comment by kreskówki — October 2, 2007

That’s fine, and good. We need to be aware of all the limitations. But both of these work well when you use them for their specific purposes – and altogether, which one is ‘better’ than the other is a largely subjective matter. I do like JSON, and I do like XML. I’m not going to use the one when the other will do the job better, however. So it’s good we discuss the limitations – but some people get very personal about it, which is not helpful to anyone including themselves.

Comment by taniec — November 2, 2007

It is good that someone writes articles which really matters something. Thank you for this article, it’s full of knowledge which is hard to find in tons of rubbish in our famous world wide web. Regards and good luck!

Comment by tapety — November 24, 2007

These technologies emerge on the horizon to improve the computing landscape, and help standards for interoperability and efficiency.
However, they should not diverge on political grounds. There is a lot of investment went on XML direction since 2000. We all had concerns on performance, security, etc especially when information, not data, is moving thru several islands. There was a cry that we are not fully utilizing hardware power, thus leading to virtualization etc. Now, we have quad-core and 8-core processors and XML parsing power is not a question as it was in year 2000. Also, why don’t we embed JSON structures into XML document, just like C# includes assembler code? We should look for options to improve XML infrastructure just like we did for TCP transport.

Comment by 122950 — February 6, 2008

The true difference between JSON and XML is the support provided by the browser. Browser supports JSON natively so, we are able to access it thru javascript with simpler notations. If browsers support XML with similar API’s, XML too will look easy. JSON looks better than XML due to support by Javascript language and nothing else. Otherwise both are equally good. In fact I don’t like JSON, because it is one more learn without much merit

Comment by QuickSoft — September 26, 2009

Using XML for Ajax is like putting a jet engine in a car. It is not wrong, just too big.

Comment by mlavannis — October 10, 2009

XML is a general purpose text format. JSON is optimized for data structures & Ajax. If a special version of XML is created which is optimized for data structures & Ajax — it will look exactly like JSON. Just like HTML can be thought of as a special version of XML for browsers.

Comment by mlavannis — October 10, 2009

JSON considerably reduces network traffic compared to XML. This is very important for wireless apps.

Comment by mlavannis — October 10, 2009

There are advantages and disadvantages for both. For me i work only with XML.

Comment by Aleve — September 9, 2010

Leave a comment

You must be logged in to post a comment.