Take the 2-minute tour ×

I'm sure lots of developers are familiar with XML and JSON, and they've used both of them. Thus no point in explaining what they are, and what is their purpose, even in brief.

If we try to map their concepts, we can say (correct me if I'm wrong):

  1. XML tags are equivalent to JSON {}
  2. XML attributes are equivalent to JSON properties
  3. XML tag collection is equivalent to JSON []

The only thing I can think of, which doesn't exist in JSON, is XML Namespaces.

The question is, considering this mapping, and considering that JSON is highly lighter in this mapping, can we see a world in future (or at least theoretically think of a world) without XML, but with JSON doing everything XML does? Can we use JSON everywhere XML is used?

PS: Please note that I've seen this question. It's something entirely different from what I'm asking here. Thus please don't mention duplicate.

share|improve this question
We can (and should) replace all of that overbloated ill-designed stuff with S-expressions, obviously. World without XML would be a much better place indeed, but that's, unfortunately, nothing but a wishful thinking. –  SK-logic Sep 16 '11 at 11:35
Ugh. I loathe these questions. I think this is really a case for using the right tool for the job, and not whether one can replace another entirely. There are so few absolutes in the world, even with computers. I couldn't imagine doing any of the things I do with JSON, at least where the respective technologies stand now. –  Philip Regan Sep 16 '11 at 12:17
A discussion about the differences between two technologies to see where improvements can be made is very different than asking whether one can be replaced with the other. The former is more scholarly review than the latter which sounds more antagonistic from frustration than anything –  Philip Regan Sep 16 '11 at 14:42
Purely hypothetical thought experiments are not on-topic here: this isn't a discussion board. If you have a specific problem you're actually facing that's prompted you to speculate about doing this, feel free to ask about that, instead. –  user8 Sep 16 '11 at 15:51
This isn't hypothetical. JSON seems to lack a feature that XML possesses. –  S.Lott Sep 16 '11 at 16:46
show 6 more comments

closed as primarily opinion-based by gnat, MichaelT, Dan Pichelman, Ozz, ChrisF Sep 25 '13 at 11:33


12 Answers

up vote 115 down vote accepted

The thing that gives XML its power and a lot of its complexity is mixed content. Stuff like this:

<p>A <b>fine</b> mess we're in!</p>

Don't even try to do that in JSON, or manipulate it in conventional programming languages. They weren't designed for the job.

This kind of question usually comes from people who forget that that the M in XML stands for markup. It's a way of taking plain text and adding markup to create structured text. It's quite handy for old-fashioned data too, but that's not what it was designed for or where it's main strengths lie. There are plenty of ways of handling simple data, and JSON is one of them.

share|improve this answer
+1: This is the distinguishing feature. Excellent point. –  S.Lott Sep 16 '11 at 12:42
@Michael, you just taught me something valuable. This is a great answer. +1. –  Saeed Neamati Sep 16 '11 at 14:15
.... There's 3 nodes indie of P, A , the B element, and ` mess we're in!`. It's an array, which you can simply explain in JSON. –  Incognito Sep 16 '11 at 18:38
@ByrneReese: yes it's XML, and yes it's valid. That it’s also HTML is beside the point; in fact, XHTML is also valid XML. :-) –  Martijn Sep 22 '11 at 17:19
There's a reason people forget what that M stands for. It's not often used for markup in practice. Still a good point about XML's advantage for that purpose. –  PeterAllenWebb Sep 22 '11 at 20:26
show 7 more comments

The main difference, I think, is in the fact that XML is designed to be self-explaining with its dtd's and everything.

With JSON, you have to assume alot about the data you are receiving.

share|improve this answer
"XML is designed to be self-explaining". Can you provide a link or a reference for this? I don't see it in the W3C standards for XML, and I'm wondering where this notion comes from. I seems like an urban legend more than a stated design goal. –  S.Lott Sep 16 '11 at 12:43
@S.Lott: I think what he means by that is the nature of XML tags, in and of themselves, allows tagged content to be self-explanatory, i.e., DTDs are optional so well-formed XML can be parsed without one. But I agree with your take on the issue because, technically, JSON has the same capability, so I don't see self-explanation being the main difference at all (I'm not sure why this keeps getting voted up), but rather Michael Kay is more on the mark. –  Philip Regan Sep 16 '11 at 12:51
@S.Lott agreed. I'd have to say the JSON here json.org/example.html is easier to understand and better self documented than the associated XML due to its lack of verbosity. –  Doug T. Sep 16 '11 at 13:00
@Michael Borgwardt: Without a full XSD (including some kind of ontology support) tag names tell me nothing. "meaningful" is hard to accomplish in general. That leaves me unclear on what "self-explaining" is supposed to mean in the answer. And I don't have evidence that it was even a design goal for XML. –  S.Lott Sep 16 '11 at 13:11
@Philip Regan: As with "self-explaining code", it appears not to be a feature of XML. If it's just a universal implementation objective that applies to all software languages (code, data access, markup, whatever) then perhaps folks shouldn't mention it around XML specifically. –  S.Lott Sep 16 '11 at 14:10
show 12 more comments

A literal translation to JSON is often less succinct and less clear. Consider:

   <x:bar x:prop1="g">
      <quuz />

The most effective JSON representation I have seen of this:

 "children": // you need to have a special array to hold all children
    {"localName": "bar",
     "namespace": "x"
        // once again, to ensure that there are no collisions,
        // attributes should be brought out into their own JSON structure 

Now, imagine that for an entire XML file. I am not saying that JSON does not have its place, but XML should not be ruled out.

share|improve this answer
Now consider SXML: (foo (x:bar (@ (x:prop1 "g")) (quuz))) –  SK-logic Sep 16 '11 at 11:48
@SK-Logic: That's great for a trivial example, but I couldn't imagine doing deeply nested, mixed content—like a book—with that. I think SXML is as much an academic exercise as anything. –  Philip Regan Sep 16 '11 at 12:22
@Philip Regan: How can be writing an S-Exp any harder then using chevronitis, when it's a trivial 1:1 transformation into a less verbose form? –  maaartinus Sep 16 '11 at 12:48
@maartinus: My field of expertise is in book publishing: textbooks of any kind are deep, complex beasts with a wide array of content that requires explicit management. DocBook and DITA are much more readable than the example given above. –  Philip Regan Sep 16 '11 at 12:54
@Philip Regan, SXML is very easy to edit, quite unlike XML. And of course it is a much better choice for protocols, needless to mention the superiority of the available tooling. –  SK-logic Sep 16 '11 at 12:56
add comment

JSON and XML are both ways of formatting data. Both are capable of doing it perfectly well, so can JSON do everything XML does? Yes.

But..... A more relevant question might not be what XML/JSON can do, but rather, what can you do with XML/JSON.

There are several things you can do with XML that I don't think you can with JSON, such as translate with XLST, search with XPath and validate with schemas. All very, very useful.

share|improve this answer
Except for mixed-content where the data contains tags. JSON doesn't do that very well at all. –  S.Lott Sep 16 '11 at 12:44
add comment

There's a lot of functionality using XSLT that may not be possible with JSON. So, if they're not functionally equivalent they couldn't replace each other.

share|improve this answer
That said, you could use another language to deserialise, manipulate and serialise JSON, and XSLT isn't XML, so this point is moot really. –  StuperUser Sep 16 '11 at 10:52
XSLT is XML -- see the schema here –  greengit Sep 16 '11 at 12:19
Thanks @greengit, I have only had a brief expose to it, updated the answer. –  StuperUser Sep 16 '11 at 12:21
@StuperUser: How could be it "impossible" with JSON? It's just a transformation, maybe the tools are missing yet. Or is the problem related to the lack of attributes in JSON? –  maaartinus Sep 20 '11 at 12:57
@StuperUser: XSLT is an language (subset of XML) for which some interpreters were written in at least one another language (probably in C, Java, ...). The same could be done for JSON (define some JSON-T, write the intepreter), couldn't it? –  maaartinus Sep 20 '11 at 15:45
show 2 more comments

JSON is fairly new and legacy systems wont support it. Upgrading legacy systems is expesive and introduces bugs. JSON wont replace XML any time in the near future.

share|improve this answer
thanks for your reply. What I have in mind, is a technical review, rather than an implementation strategy. I just want to know for example, for new versions of those legacy systems, can we drop XML entirely and use JSON? If not, what we miss in JSON? –  Saeed Neamati Sep 16 '11 at 10:42
add comment

I'd say that cwallenpoole makes an excellent point. While most XML can be translated to JSON, whether doing so is better for it is a separate point.

JSON lends itself to data structures at least as well as XML and probably better, but XML reads much more naturally than JSON when marking up textual documents, where tags are used within a larger flow of text rather than simply as a way to delimit a hierarchy of fields.

While HTML 5 may have its own parser, that still leaves applications like DocBook.

share|improve this answer
add comment

The fact is, we're going to have to live with both for a long time, and being a JSON bigot is "considered harmful."

share|improve this answer
add comment

It depends on the domain. In terms of web services? Absolutely. It's utterly shameful that vendors are still pushing SOAP on their customers. REST + JSON all the way.

Now, when you're talking about complex, structured data with style information like Docbook or other implementation? That's a proper domain for XML.

share|improve this answer
add comment

It gets ugly when you try to model these two objects in JSON:

<customer><name>John Doe</name></customer>
<employee><name>John Doe</name</employee>

Using JSON as it is used to in 99% cases one gets lost with:

{ name: "John Doe" } 

And now you have to add some meta-structures and all the beauty of JSON is gone while you are left with the downsides.

share|improve this answer
the equivalent JSON to your provided XML is { customer: { name: 'John Doe' }, employee : { name: 'John Doe' } }. So technically, your answer is not correct. :) –  Saeed Neamati Sep 20 '11 at 3:57
Sure, the only thing lacking in JSON are the attributes, and there are useless for modeling objects (unlike for markup). Sometimes attributes get used as a shortcut for what can be expressed using nested data (e.g., in Hibernate config files), which is handy but actually the existence of choice makes it harder. Config files and modeling objects are two places where JSON is clearly superior. –  maaartinus Sep 20 '11 at 13:03
@SaeedNeamati, so how would you model <customer><name>John Doe</name></customer><customer><name>John Doe</name></customer> in JSON? –  svick Sep 22 '11 at 19:26
{ customers : [ { name: 'John Doe' }, { name: 'John Doe' } ] } ? –  scrwtp Sep 22 '11 at 19:59
@Stijn -- right, and that works, but it confirms the comment from the original answer, that "you have to add some meta-structures" to model certain things that fall out more naturally in XML. –  Matt R Jul 30 '13 at 8:11
show 4 more comments

Why limit yourself to JSON when YAML is a super set and much more expressive and therefore powerful than XML or JSON.

That said, if you use the correct serialization frameworks you should be able to serialize and de-serialize all the above mentioned formats with a couple of simple lines of code.

share|improve this answer
add comment

I don't know if such a facility exists for JSON, but in .NET at least you can validate XML against a given schema. That's a valuable advantage of XML in my eyes.

share|improve this answer
add comment
