I have an application that performs a little slow over the internet due to bandwidth reasons. I have enabled GZip which has improved download time by a significant amout, but I was also considering whether or not I could switch from XML to JSON in order to squeeze out that last bit of performance. Would using JSON make the message size significantly smaller, or just somewhat smaller? Let's say we're talking about 250kB of XML data (which compresses to 30kB).
7 Answers
In terms of object serialization, JSON will generally be more compact (even when compressed). For Example:
I serialized the same instance of an object into both XML and JSON and got the following:
JSON
{
"Account": "2222",
"Login": "124235",
"SalesId": null,
"CustomerReference": "9652358474",
"Status": null,
"DropShip": 0,
"PromoCode": null,
"Notes": "For the truck",
"Errors": null,
"ReferenceId": null,
"PaymentMethod": "CKPhone",
"CheckPayment": {
"Name": "Simon Riggs",
"CompanyName": "Darth Inc",
"AccountNumber": "565555555",
"RoutingNumber": "222224455116",
"CheckNumber": "32",
"Address": {
"Attention": null,
"Street1": "555 W Portebello Rd",
"Street2": null,
"City": "London",
"State": "Texas",
"Zipcode": "45217",
"Country": null,
"ReferenceId": null,
"GetAxType": 2
},
"ReferenceId": null,
"GetAxType": 2
},
"CreditCardPayment": {
"Name": "Simon Riggs",
"CardNumber": "1111222233334444",
"Cvv2": "546",
"Month": 10,
"Year": 2018,
"Address": {
"Attention": null,
"Street1": "555 W Portebello Rd",
"Street2": null,
"City": "London",
"State": "Texas",
"Zipcode": "45217",
"Country": null,
"ReferenceId": null,
"GetAxType": 2
},
"ReferenceId": "0",
"GetAxType": 2
},
"ShippingAddress": {
"Attention": "Simon Riggs",
"Street1": "555 W Portebello Rd",
"Street2": null,
"City": "London",
"State": "Texas",
"Zipcode": "45217",
"Country": null,
"ReferenceId": null,
"GetAxType": 2
},
"Totals": {
"SubTotal": 25.0,
"TotalTax": 5.0,
"ShippingTotal": 10.0,
"ShippingTax": 1.5,
"GrandTotal": 35.0
},
"Lines": [{
"SKU": "1442-4521",
"LineNum": 0.0,
"Qty": 2.0,
"Price": 72.95,
"ShippingClass": "Ground",
"ReferenceId": null,
"GetAxType": 2
},
{
"SKU": "1212-5549",
"LineNum": 0.0,
"Qty": 1.0,
"Price": 31.15,
"ShippingClass": "Ground",
"ReferenceId": null,
"GetAxType": 2
}],
"GetAxType": 2
}
XML
<?xml version="1.0" encoding="utf-16"?>
<SalesOrder xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Account>2222</Account>
<Login>124235</Login>
<CustomerReference>9652358474</CustomerReference>
<DropShip>0</DropShip>
<Notes>For the truck</Notes>
<PaymentMethod>CKPhone</PaymentMethod>
<CheckPayment>
<Name>Simon Riggs</Name>
<CompanyName>Darth Inc</CompanyName>
<AccountNumber>565555555</AccountNumber>
<RoutingNumber>222224455116</RoutingNumber>
<CheckNumber>32</CheckNumber>
<Address>
<Street1>555 W Portebello Rd</Street1>
<City>London</City>
<State>Texas</State>
<Zipcode>45217</Zipcode>
</Address>
</CheckPayment>
<CreditCardPayment>
<Name>Simon Riggs</Name>
<CardNumber>1111222233334444</CardNumber>
<Cvv2>546</Cvv2>
<Month>10</Month>
<Year>2018</Year>
<Address>
<Street1>555 W Portebello Rd</Street1>
<City>London</City>
<State>Texas</State>
<Zipcode>45217</Zipcode>
</Address>
<ReferenceId>0</ReferenceId>
</CreditCardPayment>
<ShippingAddress>
<Attention>Simon Riggs</Attention>
<Street1>555 W Portebello Rd</Street1>
<City>London</City>
<State>Texas</State>
<Zipcode>45217</Zipcode>
</ShippingAddress>
<Totals>
<SubTotal>25</SubTotal>
<TotalTax>5</TotalTax>
<ShippingTotal>10</ShippingTotal>
<ShippingTax>1.5</ShippingTax>
<GrandTotal>35</GrandTotal>
</Totals>
<Lines>
<SalesLine>
<SKU>1442-4521</SKU>
<LineNum>0</LineNum>
<Qty>2</Qty>
<Price>72.95</Price>
<ShippingClass>Ground</ShippingClass>
</SalesLine>
<SalesLine>
<SKU>1212-5549</SKU>
<LineNum>0</LineNum>
<Qty>1</Qty>
<Price>31.15</Price>
<ShippingClass>Ground</ShippingClass>
</SalesLine>
</Lines>
</SalesOrder>
When encoded in ASCII, the JSON is 1422 bytes while the XML is 1954 bytes. After compressing them using a GZipStream, the difference is smaller but still pretty clear. The JSON compresses down to 524 bytes while the XML compresses down to 695 bytes.
Serialization/deserialization time will vary by implementation (and hardware of course) but I serialized and deserialized the above JSON and XML 100,000 times in a loop and got the total accumulative times:
JSON Serialization: 5258 ms, XML Serialization: 3266 ms
JSON Deserialization: 9582 ms, XML Deserialization: 4604 ms
So XML serializes and deserializes faster using the libraries I'm using (see below), but with averages measuring in the hundredths of milliseconds, I'd say network bandwidth and transfer time is more consequential.
(Note: I did this in C# using Microsoft's System.Xml.Serialization.XmlSerializer and JSON.Net's Newtonsoft.Json.JsonConvert classes)

- 580
- 1
- 6
- 13
Not an answer, but rather a suggestion to examine your assumptions.
How is JSON smaller?
JSON:
"person":{"firstname":"Fred",
"lastname":"Flintstone",
"age":38,
"spouse":"Wilma" }
XML:
<person firstname='Fred'
lastname='Flintstone'
age='38'
spouse='Wilma'/>
I just don't see how, in general, a JSON expression is going to be 30% smaller than "equivalent" XML. Even as you ramp up the complexity of these things, with nested structures and arrays, it's not going to be a 30% difference. It's approximately equivalent, with json earning an advantage because the end tag of a nested structure is a } , while XML earns an advantage because it need not quote field names.
If you forced me to use XML elements, like this:
<person>
<firstname>Fred<firstname>
<lastname>Flintstone<lastname>
<age>38</age>
<spouse>Wilma</spouse>
</person>
...sure, the resulting XML is larger than the prior JSON. But that seems like cheating.
Now it may be that the way you format your XML currently uses elements for everything, and that there's an opportunity to shrink the payload accordingly. But that doesn't necessarily imply JSON. If you've got tools and libraries that handle XML, you can keep XML and shrink.

- 189,189
- 101
- 473
- 713
-
76Using attributes for content is cheating. This violates well-established [principles](http://www.ibm.com/developerworks/xml/library/x-eleatt.html) of XML design. – Marcelo Cantos Apr 21 '10 at 02:37
-
8Well established? To quote from the summary of that article: *As with most design issues, this question rarely has absolute answers*. And, *In this article, Uche Ogbuji offers a set of guiding principles for what to put in elements and what to put in attributes.* Are you claiming that Uche Ogbuji's recommendations hold the weight of "well established principles"? I don't agree. And I don't agree that using XML in the same way as JSON is somehow unacceptable or confusing. – Cheeso Apr 21 '10 at 16:25
-
1Marcelo Cantos, I'm not sure there's much wrong with using attributes, unless you can explain why exactly. For example, if Auto is used with SQL-XML, then the more condensed attribute style is used (to reduce network overhead, I assume). – Nick Bolton Apr 26 '10 at 13:37
-
4"Using attributes for content is cheating" - 1) Pray tell how well formed XML is 'cheating'? If it doesn't cheat the (very long) spec, then get over it. 2) So an ASP.NET web.config is cheating, among a thousand other big-dog examples.
– Nicholas Petersen Feb 06 '13 at 16:00 -
1In the sweet and short example given by Cheeso above of the 'person' object, the winner is: XML: 80 chars, JSON: 92 chars, XML: 13% slimmer. (leaving returns but w/out insignificant whitespace) – Nicholas Petersen Feb 06 '13 at 16:04
-
3a recent analysis shows that the speed differences between xml and json is much smaller then most people realise http://www.balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html – Jim Fuller Jul 30 '14 at 07:49
-
9Attributes are fine until you need child elements, which impacts xslt/xpath, could be a big (or small) change, depending on extent of transformation logic, be careful. – raffian Dec 16 '14 at 18:54
-
9Your method only works on flat data. As soon as you start to format nested data, you have no choice as to go with nested tags. – Angelo.Hannes Jan 20 '15 at 12:28
-
5A contrived example of a single element doesn't demonstrate real world scenarios. As soon as you have a list of people the divide gets bigger. Also, XML documents typically have to have a root element and a header. – craftworkgames Jul 27 '15 at 22:45
actually this is harder to answer then it seems,
several years ago json was 'faster' but the differences have become finer between the two.
what I've observed is;
- xml compresses better with gzip then json .. time saved in download can offset other components
- xml parsing/querying in raw js is roughly equiv with json
- xml parsing/querying in jquery is much slower ... I won't begrudge jquery developers to focus on json
overall, tech that speeds up modern browsers also applies to xml processing as well.
generally, whenever I hear json touted as a 'lowfat' alternative to XML I wonder if its not some subliminal obsession with weight issues ... thats on my pessimistic days;
basically the rule of thumb I follow is
markup good for documents json good for data
and move on ... nothing to see here

- 372
- 3
- 8
-
2Excellent point that JSON is good for data and XML is good for documents. It stands to reason that XML compresses better, there's more redundant information. – craftworkgames Jul 27 '15 at 22:48
The best way to answer this is to test it yourself, since compression is involved. You also neatly avoid the XML vs JSON holy war by having an objective answer!
Since it's just a test and doesn't really need to work, you could just write up an xml->json converter in javascript that walked the XML DOM tree and copied it into a nested array/object structure then passed it to JSON.stringify(). The only tricky bit would be deciding what becomes an array and what becomes an object.
Find a representative sample (or a few) of the data being sent, convert it to JSON with your tool, gzip it and the original XML and compare sizes.
Note: I looked around for an online XML->JSON converter and they were all terrible--copius whitespace outside of quotes (illegal in JSON, alters size) and unquoted key names (ditto). Don't use them for your test or you'll get bad data.

- 1,508
- 10
- 16
Generally speaking, JSON is much faster and smaller than the equivalent XML. XML is richer in that you can store metadata (attributes) and content separately, but the same can be achieved in JSON with appropriate structuring conventions.

- 181,030
- 38
- 327
- 365
-
6I don't agree with this general statement. I can write an equivalent XML doc that is more compact than JSON, if I confine myself to using attributes. If I use more of the power of XML, as you said, using both attributes and elements, the XML document will become larger than the original JSON document, but it also holds the potential to convey more meaning. It's wrong to flatly state, "JSON is smaller". It isn't. Common use of JSON is smaller than common use of XML (where everything is an element), but the common use is not required. – Cheeso Apr 20 '10 at 17:56
-
1@Cheeso: Firstly, common use is the only thing that counts in the real world. Secondly, I suspect that only way to make XML smaller is to violate recommended practice such as not using attributes to store content. See [here](http://www.ibm.com/developerworks/xml/library/x-eleatt.html) for an exposition of some of the principles of XML design, with authoritative supporting references; note how verbose the final example is. An equivalent JSON might be: `{"menu":[{"portion":[250,"mL"], "name":"Small soft drink"}, {"portion":[500,"g"], "name":"Sirloin steak"}]}`. – Marcelo Cantos Apr 21 '10 at 02:31
-
1@Marcelo, regarding common use, I don't agree with your viewpoint. How other people format their XML has no bearing on whether I can or should use it in server-to-browser communication in *my* app. Aso, regarding the article, it's fine to make recommendations, but what weight do they hold in this particular case? Why follow them? As I said in my full answer, if you force the XML to be verbose, it will be verbose. If you allow yourself to use the more succint XML usage, then it will be comparable with JSON in length. – Cheeso Apr 21 '10 at 16:28
-
1@Cheeso, On common use: When someone sends you a SOAP packet, you can't say, "Can I have all attributes, please?" If you live on an island, by all means do whatever you want, but that's not what XML is about. On the article: Getting from A to B is much quicker at double the speed limit. XML design guidelines aren't plucked from thin air; the authors hope to steer you clear of blind alleys. You can disagree, just don't argue that your XML is succinct because you ignore good advice. Also, my JSON example has the same structure as in the article. You can only shrink the XML by hiding structure. – Marcelo Cantos Apr 22 '10 at 00:37
-
2You are correct, if someone else picks the data format, I can't ask them to change it. But that's not what the original question was about. In the orig question, the asker was choosing the data format. Regarding the "hiding structure" side effect of shrinking XML, you are correct. But you fail to mention that JSON lacks that structure; the shrunken XML duplicates the structure of a JSON representation. As for "that's not what XML is about"... I have no idea what that means. You seem to want to argue strongly against the idea that XML is of comparable size to JSON. Not sure why. – Cheeso Apr 22 '10 at 01:26
-
1@Marcelo: where is the evidence that backs up the "much" faster and smaller aspect of your answer? – vtd-xml-author Apr 22 '10 at 02:01
-
@Cheeso, please don't attribute motivations to my arguments. I believe something contrary to you, and I try to make my case; you are doing exactly the the same. You are stepping dangerously close to _ad hominem_, which would not be in the spirit of SO. – Marcelo Cantos Apr 22 '10 at 10:30
-
@vtd-xml-author, The "much" smaller is obvious in my example which has half as much line noise as the XML example it is based on. I don't have data on the speed, but a full-blown XML parser has far more work to do than a JSON parser, so I would be very surprised if they were close to each other in performance. – Marcelo Cantos Apr 22 '10 at 10:32
-
1Marcelo, re-read all of my comments and you will see that there is no attack on you, or on anyone. I remarked that you seem to be arguing pretty strongly, but yet without a good foundation. You say things like "that's not what XML is about" and "common use is the only thing that matters in the real world". These are not technical arguments. To me, this is evidence of reaching, and I pointed it out. The size equivalence of JSON and XML is staring you in the face, and somehow you keep asserting that XML is larger. It just isn't, no matter how many times you repeat the assertion. – Cheeso Apr 22 '10 at 14:07
-
also, Marcelo, I find your other points to lack relevance. As you point out, I cannot ask a SOAP server to reformat its response. But that is absolutely irrelevant to the question at hand, which is - *is JSON smaller than XML?* It is also irrelevant that an XML document that uses attributes rather than elements sacrifices structure and the potential to carry extra meaning. JSON also lacks this. When comparing XML to JSON, why compare XML-with-elements to XML-with-attributes? Your inability to address these issues is why I remarked that you seem to have a desire to argue despite the facts. – Cheeso Apr 22 '10 at 14:11
-
You assert that XML is no bigger than JSON. I assert that this can only be so if you ignore well-established XML schema design principles (not just by the one blogger, but also by the references he cites and plenty of other materials I've read over the years). Interpreting my disagreement as "reaching" is misguided at best, disingenuous at worst. This debate is going around in circles, so feel free to have the last word. I'm done. – Marcelo Cantos Apr 22 '10 at 21:54
-
If I may chime in... I belive that Marcelo's viewpoint is possibly leaning toward dogmatic. I feel as if I would lend preference to Cheeso's opinion because it sounds like it might be based on professional experience rather than theoretical research. I'm guessing that Cheeso did not respond to Marcelo's last comment because his forehead was getting sore. – Nick Bolton Apr 26 '10 at 13:46
Yes JSON would be about 30% faster there are fewer characters going over the line and its very quick to parse.
Ypu could also take a look at "YAML" which sends an absolute mininmum of metadata in the message.

- 27,109
- 7
- 50
- 78
-
4
-
The 30% is just my personal perceived experience. You can write more compact exml using atributes rather than tags but XML tends twards a "longer is better" way of thinking and compact XML will look "wrong" to any xml guru. Also because JSON is pretty much JavaScript its pretty easy write an efficient parser in JavaScript ( something more than "eval" which works on most JSON!) and frameworks like DOJO have excellent JSON parsers. – James Anderson Apr 22 '10 at 01:18
-
1The reason why XML seems to favour elements over attributes is the fact that you can control elements and their contents far better than you can control attributes and their contents. My source is personal experience with WXS, though I have a feeling that RNG would disprove that idea. It's all a matter of personal experience. Generally though, XML looks better with elements than with attributes, and elements are a requirement in some cases (unless you want attributes like "person-1", "person-2", ..., "person-N"). That means that similar JSON (they can't always be equivalent) is smaller. – Dustin Apr 22 '10 at 01:43
-
I hate to play devil's advocate, but 30% does sound like a made up figure! ;-) – Nick Bolton Apr 26 '10 at 13:38
<person firstname='Fred'
lastname='Flintstone'
age='38'
spouse='Wilma'/>
"person":{"firstname":"Fred",
"lastname":"Flintstone",
"age":38,
"spouse":"Wilma" }
XML: 80 chars
JSON: 92 chars.
XML is the 13% slimmer winner, who would have thought for all the bogus claims?
[Example taken from Cheeso above. Note that carriage return types change the size but equally for both. Without any returns in either, the ratio is XML: 74, JSON: 86, a 14% difference]
Someone claimed in this discussion that "using attributes for content is cheating" (citing [this][1]).
1) Pray tell how well formed XML is 'cheating'? If it doesn't cheat the (very long) spec, then let's please get over it. Valid is valid.
2) In that case an ASP.NET web.config is 'cheating', among a thousand other big-dog examples.
<forms loginUrl="~/Home/Login"
defaultUrl="~/Home"
timeout="2880"
requireSSL="false"
slidingExpiration="true" />
To be fair, there are those who tend to have a bloated-XML mentality in how they form the XML.
But it should not be said that the 13% slimmer XML variety is not just as valid. And thus it even beats JSON (in size).
[1]: http://www.ibm.com/developerworks/xml/library/x-eleatt/index.html [2004 article, mind you]

- 9,104
- 7
- 59
- 69
-
9Not "cheating" but certainly a very poor example for comparison. It's highly optimised to make XML win (it doesn't even use any non-self-closing tags which typical XML files are full of). – NickG May 16 '13 at 16:26
-
Hey @NickG, you shouldn't give down votes for matters of personal preference, particularly when my answer was 100% factual and scientific in nature. – Nicholas Petersen May 19 '13 at 04:09
-
Further, the only detail you shared for your criticism would seem to say you are a novice at XML usage (and that's not an insult). You criticize for using self-closing tags in XML??!! Unbelievable. There are many people like me who prefer, as a rule, to use self-closing tags whenever its possible or appropriate. This is standard usage. – Nicholas Petersen May 19 '13 at 04:15
-
10You're totally missing my point. The example you've used is for the ideal case of "flat" tabular data which could easily be stored in CSV even more efficiently than JSON. XML was invented to fulfil the need to store multi-level data (a data tree) or to represent objects in serial form. When data is heavily nested, you cannot store every record on one line with attributes only and a self closing tag. You've basically chosen the best case scenario (flat data) rather than a more real-word example XML was designed for. – NickG May 19 '13 at 08:20
-
2I give up. I have no problem with self-closing tags; I use them myself all the time. As I clearly said, I only have a problem with the poor example you used to demonstrate your point. As you're clearly offended by comments, I'll upvote your answer again when the site allows me to. – NickG May 20 '13 at 08:50
-
Buddy, it is not a poor example. I was not paid to give a whole article, in which case I could have given 10 pages of real-life full examples. But even with full nested documents, as I just said, you would find that in the majority of cases, the end elements are the most numerous ones, so then the only thing extraneous would be the parent end elements, MEANING: the result still stands! Namely, ***IT SHOULD NOT BE SAID THAT XML IS ALWAYS LARGER***, actually, if anything, when done without the bloated XML mentatility, they are equal, though sometimes XML even is 10% or so smaller! – Nicholas Petersen May 20 '13 at 15:25
-
its not that we have a bloated XML mentality, but that you have a freaking obsession with xml. Both yours and his arguments are valid, although i feel like you still miss the point with you "out in the green" *baby-ish" example... – glace Jan 09 '19 at 10:07
-
It's poor example. Is has only one node. And that's excemptional case. It does not use main feature of XML and JSON: the ability to hold complex data. You could go further and compare to {p:{}}. JSON will be 50% larger then XML. but that's will be an example as bad as you provided. – babay May 26 '19 at 03:20