Is JSON the Developer's Choice?

Once upon a time there was the great debate over JSON vs XML. The past few years have seen JSONs popularity rise despite XML (and other formats) being well-established. Our own statistics on ProgrammableWeb show a significant increase in the number of JSON APIs over 2009/2010. During 2009 there were only 191 JSON APIs registered. So far in 2010 there are already 223!

But the increase in JSON APIs doesn't appear to be at the cost of XML APIs. Undoubtedly some providers are setting a preference of one data format over another, but it seems the greater majority are simply making their data available in both formats, especially as many application frameworks make this a fairly painless task.

This is good news for us seasoned developers as we have more choice. For newer developers though, choice can be more of a hindrance than a help. Even for more advanced programmers, the question of which format to use can be a tricky one to answer.

Tweet from @schleyfox clearly a bit scared of XML APIs

It seems that many developers are choosing JSON based on its apparent syntactic simplicity when compared to XML. Others seem to base their choice on the medium of consumption e.g. a server-side language or Javascript in the browser. Still others would quote perceived performance issues.

I prefer JSON for client-side Javascript use. This is purely and simply convenience because once decoded/parsed my data is addressable in standard notation and I don't have to write too many extra variable declarations and function calls to extract the data.

However, I think David Megginson put it most succinctly:

"Personally, I like XML because it’s familiar and has a lot of tool support, but I could easily (and happily) build an application based on any of [them] — after all, once I stare long enough, they all look the same to me."

All said and done, it seems as though personal preference, context and the needs of the application are the most important factors in determining which format to use. Ultimately, though, isn't it the data that's most important?

Which format do you prefer to consume and why? If you're building APIs, what challenges are you facing making data available in both formats? Let us know in the comments!

Be sure to read the next Best Practices article: Web API Documentation Best Practices


Comments (26)

[...] weather data API to return JSON, as well as XML, a move that’s with the times. More and more, JSON is the developer’s first choice. Related ProgrammableWeb ResourcesLearn more WeatherBug GEO API [...]

[...] First, it adopts the REST style over Version 1 that was based on SOAP. It also provides data as developer-preferred JSON. The changes make the API easier to use, which is good for [...]

"parsers are overly complex and picky."

One man's picky is another man's precise. JSON is simpler, and that influences its usage. I can see the potential future need for the verbosity of XML. When APIs start needing to speak in richer semantics, I bet XML will regain some popularity.


You hit the nail on the head. Consuming something that's already in the same relative form factor saves coding time and makes mistakes less likely. Also, they are both ways to express information. I feel that it takes less to be more expressive using JSON than XML. It's also more human digestible. Furthermore, parsing/tokenizing/serializing XML almost always consumes more resources (in PHP and Python so far as my experience with them has shown).

To sum up, they both serve the same purpose and have similar semantic qualities (when left in the hands of a skilled programmer) leaving only performance and ease of use to consider heavily. My experience leads me to believe that JSON is the better tool in most cases because of that.

For the RESTx project ( we allow custom components to be implemented in Python as well as Java. Natively, we use JSON for most exchanges, but since there are plenty of XML APIs out there, and since our Java developers may be more familiar with XML and the tooling around it, we will add XML support very soon as well.

RESTx is a platform for the simple and quick creation of RESTful web services and it takes care of most of this sort of encoding based on content negotiation between client and server. So, component developers normally don't have to deal with it, at least not inside of RESTx components.

I prefer JSON. In Ruby, JSON parsing is much much faster than XML and navigation is usually a lot easier once it's parsed.

JSON all the way.

Somebody in a google tech talk called Javascript sort of a crippled Lisp with C syntax, since Javascript, to a large extent, uses its own data structures to describe/encode programs (only the innards of functions are different, but functions are a primary type in Javascript). And moved on to say that due to the many web apps and dynamic web sites out there, most code today in one particular language is Javascript code.

Somebody else thought of creating node.js, and bring Javascript to the server. HTML 5 made a whole lot things possible in web apps which were at best difficult but in many cases impossible with XHTML 1 or HTML 4. Am I the only one to see a pattern here? What do you think will the language/data format/API of choice tomorrow?


At MindTouch, our APIs have always been natively XML, but provide options to consume information in JSON or serialized PHP with more options to follow as new representations become popular.

XML has the richest semantic structure and a clear composition model, which enable documents to evolve dramatically while remaining backward compatible. None of this exists natively in object-based representations, but require conventions and discipline instead. For that reason, XML is the better format, though it undoubtedly has some warts.

All else being equal JSON uses less bytes than XML. Less bytes over the wire makes the app faster. Faster is better. Ipso facto JSON is better than XML.


Twitter said that version 2 of their API will be JSON only.

Agreed. The speed of JSON makes it an attractive choice. In PHP json objects are serialized and un-serialized faster then standard arrays. XML is a dog and parsers are overly complex and picky.


To be honest it depends on what platform I am working, python and php then json but .net XML.


I used to be an XML evangelist for years, but now that I'm coding mobile apps, JSON is a clear winner, especially for offering reduced bandwidth. What's more, in Apple's iOS SDK and Objective-C, it's relatively easy to parse JSON strings into array and dictionary (hash) objects.


To add to what I said above, JSON's "lighter" bandwidth and processing offerings are really noticeable for mobile apps that are query-intensive

JSON is easier for most uses. XML has some nice features but is more complicated and often overkill when you just want to get some data from an API. JSON provides the path of least resistance in most cases.

[...] API providers and developers are making their choice quite clear when it comes to choosing between XML and JSON. A nearly unanimous choice seems to be JSON. Several API providers, including Twitter, have either stopped supporting the XML format or are even introducing newer versions of their API with only JSON support. In our ProgrammableWeb API directory, JSON seems to be the winner. [...]

[...] updating data through REST APIs. It makes use of existing, familiar technologies like AtomPub and JSON but attempts to provide a consistent structure for their use across implementations. OData’s [...]

[...] realm of socially based services. We’ve been chronicling JSON’s emergence over XML as the developer’s choice in data formats, it’s no surprise that Foursquare is moving in that [...]


JSON does not support references so more data is need to be generated and transmitted across the wire than the xml version, assuming both are text encoded. Does this make it therefore slower?

[...] XML-RPC or other protocols, JSON is gaining ground on the old favorite, XML. Last fall we said JSON is the developer’s choice and therefore it’s becoming the API provider’s choice, too. XML still wins overall, but more [...]

[...] XML-RPC or other protocols, JSON is gaining ground on the old favorite, XML. Last fall we said JSON is the developer’s choice and therefore it’s becoming the API provider’s choice, too. XML still wins overall, but [...]

[...] API’s bieden meerdere output formaten aan, meestal XML en JSON. Ontwikkelaars zijn gek op JSON. JSON is lekker simpel, niet te veel overhead, etc. Dit is de reden waarom veel API’s [...]

[...] with 26 Weather APIs listed in our directory. While XML is still the leading data format used, the trend of JSON becoming the developer’s choice over the last few years is also reflected in the Weather category. Since the beginning of 2010, [...]

[...] First, let’s take a step back and look at why JSONP is important. The reason is tied very closely to why JSON is popular in the first place. JSON stands for JavaScript Object Notation. It can be directly translated into a JavaScript object. No parsing necessary, just get at the data. With web apps becoming more JavaScript-dependent, it’s clear JSON is the developer’s choice. [...]