I'm wondering about the differences between XML and JSON.

Without any regard to existing processing tools and backend systems and merely as a means of representing data is there anything JSON does better than XML or vice versa? Or can they both be used to the same extent ?

I.e. is there anything that could be represented by JSON that XML could not represent or vice versa?

4 Answers 4


XML and JSON are both capable of transmitting the same data, but which is better depends mostly on what you want to do with it.

This does touch on existing tooling, but you're not likely to be hand rolling parsers for either, so it is relevant.


  • Has better tooling for verifying schema.
  • Has built in support for namespaces.
  • Can be more easily restructured into HTML.
  • Can be queried with XPath, which is really exceptional query language - think SQL for XML. I haven't really seen an equivalent for JSON - but I'd love to hear about it if I'm wrong on this one.


  • Has significantly lower ceremony (and, at least in my experience, better pretty printers), so when a human has to look at it, it can be easier to read.
  • Is, unsurprisingly, the best format when one end of the transfer is written in JavaScript.
  • Has less legacy, so the chance of being forced to accept malformed JSON is lower. There is also no cultural expectation that you should have to accept malformed input.

Because one is capable of storing anything that can be stored in the other, usability and tooling is about the only criteria that is useful for comparing what it's like to use them.

If all that were wiped away, I'd probably use neither, and transmit the data as chunks of Lisp.

It's lower ceremony than JSON (barely), much easier to transform than XML, and easier to write a parser for than either (which I'd have to do if all the tooling were gone).

  • 2
    XML has namespaces, and is generally better for complex hierarchies. See also programmers.stackexchange.com/a/108764 Commented Nov 11, 2015 at 15:27
  • There's been some recent activity related to idioms for this is JSON, but you're right that it is easier to do in XML.
    – Morgen
    Commented Nov 11, 2015 at 15:29
  • Are you kidding? Lisp has immense amounts of ceremony, precisely because it's so trivial to parse: all of the useful semantic data built into a richer language's parse tree isn't there in Lisp, so all that burden gets shifted onto the developer's shoulders. Commented Nov 11, 2015 at 15:35
  • 3
    I think we are using different definitions of 'ceremony'. I meant this in the sense of “that which is done because that's the way it's done”. For example, a list. In psudo XML it would be <list><item>one</item>...<item>n</item></list>, there's a bunch of stuff in there that adds very little actual value. In JSON that same list would be ["one",..., "n"] , much less stuff there that doesn't directly add value. In Lisp it would be ("one" ... "n"), even less so. Granted, similar to how JSON is a subset of JavaScript, I would not advocate for a full Lisp implementation for data transfer.
    – Morgen
    Commented Nov 11, 2015 at 15:54
  • "the chance of being forced to accept malformed JSON is lower" - I haven't used any parser yet that gives you the slightest chance to accept malformed JSON. If it's malformed, parsers throw it away. So you can't accept it, therefore can't be forced to accept it. Thank heavens for that.
    – gnasher729
    Commented Oct 19, 2019 at 11:29

XML is an eXtensible Markup Language. That's important to understand: It's designed to be essentially like HTML--a document markup language--but a bit more formalized. Problem is, document markup isn't what anyone uses it for. People abuse it for data storage and data exchange, which is a really bad idea because data storage isn't anything like document markup.

A typical HTML document has a pretty high content-to-markup ratio. It's quite possible to write entire pages without needing to insert a single tag beyond the occasional <p>, for example. But in data storage, every data element needs to be defined in some formal way. With XML, that turns everything into a mess of tag soup very quickly. For example:

Some people, when presented with a problem, think “I know, I’ll use XML.”

<Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription> </Problem:Worsening>

We see that the content can very easily end up completely drowned out by all of the tags. (This is often true even when the XML has been pretty-printed.)

Also, XML requires that every <tag> must be closed by a corresponding </tag>. It also requires that tags be closed in strict LIFO (ie. Stack) order. This is redundant: if the only tag that's valid to close is the last one that hasn't been closed yet, every closing tag could theoretically be a simple </> with no loss of semantic information. (It would be harder to follow if you didn't pretty-print it, but who wants to try to read non-pretty-printed XML anyway?) This makes XML files larger and bulkier than they need to be.

The XML DOM model is also incredibly complex. Just for starters, you have two distinct ways to represent sub-data on a node: nodes between the opening tag and its closing tag, and Attributes inside the opening tag. Again, this is an idea that makes a lot of sense in document markup (<a href="http://example.com">) but a lot less for data storage. Then you've got all sorts of additional complexities like namespaces, schemas and validation, XSLT, and so on...

The principal difference between XML and JSON is that JSON is just a data storage format. It's optimized for expressing serialized data, not for document markup, and so it does a much better job of expressing serialized data. Douglas Crockford calls it "the fat-free alternative to XML."

The really interesting thing is, it manages to do this without actually losing any power. You want schemas and validation? Use JSON Schema. Queries? There's JSONPath for that. (And if, on the other hand, you don't care about those things, you don't need any code for it bloating up your program.) You want comments and namespaces, or even attributes? {"namespace": "MyNamespace", "attributes": {"attrib1": "value1", "attrib2": "value2"}, "data": "Insert content here", "comment": "It's that simple"}

To answer the original question, there's no data that can be represented in either system that the other can't also do. It's just a lot smaller and cleaner in JSON, almost every time, because JSON was specifically designed for data storage and XML wasn't. It's a simple matter of "use the right tool for the job."


It's a bit of apples and Oranges. They are both used for the same task yes, but they are distinctively different.

XML is Extensible Markup Language. The main benefit of it is that it can cary meta data. In short:

<tag attribute="something">data</tag>

So having attributes on your elements allows you to be more explicit.

More on that you can have predefined schema that enforces your defined rules of the structure. For e.g. certain elements might use certain attributes, but if others try to use it, schema validation would give you an error.

This gives a lot of power. But with great power comes great responsibility. Often these XML's represent structures and relations more than the data it self. Thus it becomes hard to read for a human because of all of the additional information it carries. So for some operations it causes more of a bloat since you want to save 5 lines of data while having 20 or more lines of xml because you need to satisfy the schema.

Wikipedia has quite a good summary of it: https://en.wikipedia.org/wiki/XML

JSON on the other hand is only meant to represent data and nothing more. You get main types of data:

  • Integers
  • Strings
  • Booleans
  • Arrays
  • Dictionaries

Thats it. You can nest them in any manner you want but thats your limitation. You only use those data types. More here: http://www.json.org/

Sure you can move attributes to their own array within the dictionary or so and you could achieve most of the same, and thats why there is this comparison often is mentioned. But at the core of it these are 2 tools for different uses. Just when you get a hammer everything becomes a nail.

XML is great when you have complex structures, relations between objects, maybe even overrides of one file by another (handled by another answer mentioned XPath).

JSON is great when you need to communicate with small objects that could have their own validation done in code. Also it's human readable and dead simple.

  • I disagree with the attributes argument for XML; the XML <tag attribute="something">data</tag> can be replaced by the JSON { title: "tag", attribute: "something" , data: "data" }
    – bzr
    Commented Nov 17, 2020 at 19:09

Json is is the text representation of an object containing data and only data, it has nothing else. The else, that I'd often wished it included(but does not as a completely valid design decision of being the serialized text representation of a JavaScript object):

  1. Comments, especially in Json config files. People are often reduced to dummy fields like _comment.
  2. A schema describing everything that could possibly be in an object, e.g. you have an API that returns an object representing a patient's appointments, you think you know all the data that it could contain, you have a sample set of what have been told is the exhaustive list of all the possible appointment types and you've tested them all, but you don't have access to test vs all prod data due to privacy. Then you deploy your code to prod and it goes splat immediately, because it turns out that API aggregates data from several systems and even the people who developed it don't know all the possible appointment types a patient might have.
  3. Data types, Json only has String, Number, Boolean, Null and Array. This comes to bite you in the ass particularly hard with dates, since you have to parse Date/Time strings all the time and you can never be sure of the exact format(see point 2 above).
  4. Also related to data types, if you get a list heterogeneous objects, i.e. something like [{//FOO object},{//BAR object},{//BAR object}], parsing becomes a pain in the a**.
  5. When working with strongly typed languages, no way to guarantee that Object_A -> A_Serialized == A_Serialized -> Object_B, without a ton of work to manually cover all the edge cases.

However, then you start working with XML data and you run into:

  1. Trying to read a lot of XML serialized data makes your eyes bleed.
  2. Resolving complicated namespace issues will make you want to become a monk.
  3. XSLT and XPATH sound good on paper, and really are powerful, but writing complex queries/transforms and especially debugging them will make your eyes bleed and want to become a monk.
  4. The resulting XML representation of the data is significantly larger, made worse by the fact that binary Json implementations, like BSON, JSONB and CBOR are way more robust and developed than Binary Xml. You may be reduced to gzipping zml data for transfer, with all the joy that that entails.

So yeah, any piece of data could be serialized as either JSON or XML, there's no edge case that can't be worked around with enough effort, it just depends on what kind of headache you want to deal with. IMHO, with JSON it's easier to shoot yourself in the foot with bad communication, documentation and project management, while XML makes you want to shoot yourself in the foot.

Not the answer you're looking for? Browse other questions tagged or ask your own question.