I understand the purpose of XML, but I always hear people complain about how BAD it is? I don't really understand whats so bad about it? I usually hear the terms "bloated" and "slow" tossed around.

But I guess as programmers, what do you mainly use it for? And do you really consider it "bad"....because if it is, an awful lot of people use it for transporting of data...

  • 1
    Your answer is in the question. People still use it because people used to use it, and the options are (1) rewrite all the code that used it before JSON and YAML, or (2) suck it up and do the stupid thing. A lot of people still perpetuate cycles of violence, too. That doesn't prove the inherent worth of the practice. Commented Apr 27, 2015 at 1:45
  • 6
    Try JSON for an actual document (man page, Knuth, Hamlet, etc). You'll then understand why XML is essential. This is a space where JSON sucks (go ahead, try). Using either one in the other's design space is questionable. The problems from using XML in JSON's space are mainly verbosity and speed, while the problems from using JSON in XML's space tend to involve portability (try to interoperate with a friend who did a book in JSON, but their own way), integrity, and interpretation problems that require lots of human effort to fix. Use the right tool for your job.
    – TextGeek
    Commented Oct 8, 2015 at 22:15
  • 1
    XML is only bad because many people abuse it for things out wasn't designed for. If you don't need your data to be readily extensible (i.e. the scheme is used by multiple parties who need to interoperate, rather than centrally dictated by one authoritative party), and if your data isn't a document (i.e. if DOM would've been a poor abstraction of your data), then XML isn't suited for those applications. When your problem domain falls under what XML is designed for though, nothing else matches XML. JSON, YAML, etc are poorly suited for the space that XML really are designed for.
    – Lie Ryan
    Commented Mar 27, 2019 at 3:37

12 Answers 12


Xml is great for what it was designed to be -- a platform neutral, human readable data transfer protocol with some capabilities to enforce data validation at low levels. I doubt anyone who uses Xml in this manner has a real complaint. Is it the most succint wire format? No. But there are worse options. Is it as fast as reading your custom binary format? No. But your business partners can read it in whatever stack they are using.

The problem, however, is that humans -- especially the breed known as enterprise architects -- are evil and take good things and make them bad. In the case of Xml, the early part of this century saw Xml as the universal hammer for every IT problem. Sprinkle in a little design by committee and you end up with some horrible monstrosities like SOAP and oXML. Neither of which should be wished on enemies, nevermind friends or colleagues.

  • 16
    +1 - anyone who has ever had to deal with EDI just wishes XML had been invented before that mess came about. Commented Mar 23, 2011 at 17:46
  • 12
    +1 Matches my thoughts almost exactly. I'd only add that for storing plain and simple data, even if it's a hierarchical (but not too deeply, that doesn't blend well with anything), there are certain formats that work just as well - most notably JSON and YAML. The latter is imho awesome with regards to human readability.
    – user7043
    Commented Mar 23, 2011 at 18:01
  • 12
    To paraphrase jwz: "There's a certain kind of programmer who'll look at any problem and say, 'I know, I will use XML.' Now he has two problems." Commented Mar 23, 2011 at 18:23
  • 14
    Please tell me oXML was intended as a joke, like Brainfuck or Whitespace or LOLCODE.
    – dsimcha
    Commented Mar 23, 2011 at 18:32
  • 10
    @Shamim Hafiz, SOAP is definitely among the worst monstosities ever bred by the mankind.
    – SK-logic
    Commented Mar 24, 2011 at 10:48

XML is just a tool that comes in many flavors and uses. XML excels at some things and sucks at others. I think one of the problems is that people have seen "enterprise" XML that is needlessly complex with namespaces and crap strewn around (SOAP, anyone?). The trick to designing XML formats for humans is adding real meaning to data while not making them overwhelming to read.

One of the things people take issue with is that XML sometimes chokes on some character or some missing bracket. There is, however, both an upside and a downside even to that. The upside is that you don't have ambiguity like you have with HTML where different cases of semi-invalid syntax can be interpreted differently.

The downside is that it's a bit harder to author and harder to learn. I agree there's an argument to be made that the web wouldn't have become to big so fast if HTML was as stringent as XML, but I'd also argue that we'd be glad if it did today. :)

Also, do not use it for everything just because you can, have the sense and judgement to apply it appropriately. If all you have is XML, you tend to always be an XSLT transformation away from what you want. :)

I'd argue that the format only really matters when humans need to interact with it. If you're writing some program that serializes something and sends it somewhere where it is to be consumed by another of your programs, who cares what it looks like so long as it's as efficient as possible? Use a binary format or bunnies and unicorns for all I care.

Pros of XML

  • Covers a lot of edge cases that YAML and JSON don't
  • There are excellent tools for parsing and validating XML in an array of different platforms and languages
  • XML can easily and powerfully be transformed into another format (through things like XSLT)
  • Reasonable XML documents are simple for humans to read and edit; don't tell me JSON is easier, it isn't :)
  • XML is self-describing to some degree, i.e. it directly contains information about its structure and meaning (in contrast to most binary formats)
  • Handles encoding
  • Whitespace agnostic, which makes for easier cross-platform use
  • Breaks if it isn't well-formed (Ensures data is structurally correct)
  • It's not SGML


  • Verbose
  • It's not as fast to parse as binary
  • Breaks if it isn't well-formed (crashes your application)

Good uses

  • Configuration files
  • Data interchange formats
  • Version resilient file formats
  • Storing documents in databases

Not so good uses

  • Data transfer formats
  • Serializing Objects
  • Storing relational data in databases
  • File format for high performance I/O scenarios
  • 15
    I doubt that "configuration files" should be under "good uses". They aren't data, rather instructions.
    – daknøk
    Commented May 3, 2012 at 9:44
  • 3
    I am with @daknøk here - I can't count the times I had to spent huge amounts of time figuring out a configuration bug in a hunderds of lines long XML-file that specifies the dependency injection, that was based on one small typo in an XML-attribute.
    – Gjallar
    Commented Oct 27, 2012 at 10:32
  • 3
    If bad data crashes an app then is it the data that has a problem? Commented Jun 11, 2013 at 17:03
  • 5
    Any file format that is malformed/corrupt has the potential to crash broken software. So XML is not the culprit here... just your application. Otherwise, good post. Commented Apr 7, 2014 at 21:18
  • 3
    Could you expand on "Covers a lot of edge cases that YAML and JSON don't."? Commented Jun 15, 2016 at 15:12

Jeff Atwood has a pretty good blog post at XML: The Angle Bracket Tax about this if you want a source talking about it.

The most common uses I have for it are:

  • Services talking to each other. For example, a website using a content management system has to send some data into a customer relationship management system and this is done with XML.

  • Configuration storage. Web.config and app.config being common examples but nAnt scripts can also use some XML to them as well.

I don't think it is optimal but that alone doesn't make it bad to my mind.


Two reasons:

  1. There are an awful lot of bad programmers out there. XML may be bad, but it's also simple (on the surface at least) and makes it very easy to write bad software. Sorta like VB.
  2. A lot of the people making these decisions aren't programmers, but business types who have only heard that "everyone's using XML" and so they decide they want their product to use XML too.
  • What an absurd and totally useless points. 1) XML is far from bad and it has absolutely nothing to do with the quality of the software people write whether they choose it or not, I've seen quite good VB programmers, implying that if you use VB you actually write bad software is just silly because there's a complete disconnects between how you write software and with what you use to write it. 2) Yet another false assumption, choosing XML is great and most of the people that are choosing it for better or worse are certainly programmers. XML isn't silver bullet but it's good for certain things.
    – eyalalonn
    Commented May 27, 2016 at 1:50
  • 2
    @EyalSolnik: 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> </ProblemWorsening> Commented May 27, 2016 at 10:45
  • 5
    Just because people abuse something doesn't mean the technology itself is bad, you can see the same syndrome in many places.
    – eyalalonn
    Commented May 27, 2016 at 18:46

I usually hear the terms "bloated" and "slow" tossed around.

It's not the most compact syntax, but it's clearly the most expressive one. Human readable? depends on how you design your language. Most people do not design a language for XML, they just serialize objects as XML.

…why do so many people use it?

It's ubiquitous. You can query an XML database with XQuery, transform the results with XSLT as XHTML or Atom, get Atom or other XML format from other web services, get XML from users using XForms, validate it with XMLSchema, Relax NG or Schematron, process it with XProc, save it back to the database with XQuery Update. All these tools understand XML, so there's no need for mapping between different representations.

XML is not a serialization technology, it's a general purpose information set.

  • 1
    ... and we ask ourselves for years why for chrissakes SOAP has been built upon XML.
    – JensG
    Commented Apr 7, 2014 at 18:59
  • Verbosity = redundancy = error correction = readability = robustness in the face of noise/decay/human-error. Not such a bad thing, imho.
    – TextGeek
    Commented Aug 23, 2023 at 15:24

Here, we use it for data exchange between different systems made by different vendors with different internal representations. We build an XML transformation/interchange system to shuttle the data back and forth. It works fine for that.

XML is not inherently bad, but I acknowledge that designing a "good" solution using XML is not trivial.


In my experience, people mostly complain about the way it gets used, not the technology itself.

The bloated and slow bits that people complain about are usually the libraries/methods that are used to fetch info from it.

I use it for storing small amounts of structured information that I want to store on disk (without a database or binary serialization), or pass to another application (which essentially describes SOAP as well).


"The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." -- Phil Wadler, POPL 2003

My personal opinion is that so long as you don't care about validation, schemas, XSLTs and the rest ugly stuff and you keep the size of the files small (otherwise parsing becomes slow) you can find some good uses of XML (an example is for configuring your application instead of using INI files).

  • Otoh, if you "don't care about validation", your code and data will not be very robust. Maybe being able to check if the data is corrupted is "ugly stuff", but I for one want it. Also as noted already, good luck doing documents in JSON etc. Got a better solution for that problem, not the problem JSON aims at?
    – TextGeek
    Commented Aug 23, 2023 at 15:27
  • There are better and more compact ways of doing validation. For example avro and protocol buffers.
    – sakisk
    Commented Aug 24, 2023 at 18:43

Its Good because:

Its a standard "Interface" that multiple heterogeneous systems can use to communicate with. And is "Human" Readable (kind of, try staring at 5 MB XML)

Its Bad because:

Its bloated, larger size = more bandwidth = more $$

There are other reasons, everyone has a different gripe...

  • 4
    @Darknight: I challenge the human readable by throwing Xml Entities at you... (personal peeve) Commented Mar 23, 2011 at 17:51
  • 2
    I don't think XML is inherently bloated - but implementations of it are. I find XML-RPC to be particularly egregious at unnecessary bloat.
    – HorusKol
    Commented Mar 23, 2011 at 22:18
  • 3
    @HorusKol: <advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator> The ratio data/markup is so low... I call this "bloated". JSon, for example, would be only as half bloated: advanceAcceptanceIndicator: "Y". There is also the fact that text between tags is valid, so when reading Xml, you need to decide what to do with this cruft \n\t\t\t, and the solution is generally to just ignore it, because you were never really interested in this to begin with. Commented Mar 24, 2011 at 7:15
  • 1
    @HorusKol: It would, but I never said it was a boolean value, it just happens to be a single char :) The use of attribute here (value ?) would probably be superior too, because people could be tempted to insert whitespaces between two tags. Commented Mar 25, 2011 at 7:31
  • 2
    "Its bloated, larger size = more bandwidth = more $$" I guess compression hasn't been invented where you are yet.
    – Andy
    Commented Jul 18, 2017 at 1:16

Like for any other technology: there are many available tools and libraries.

I don't like XML, especially because it's funky, when people say it's human readable, they joke, I think, or have never really read an xml when one tried to embed xml in an attribute... the xml entities make it really unreadable. Furthermore, it's amazing how much space gets wasted because of the redundant end-tag, and the ability to mix free text and data...


  • Xml can be specified (xsd) and tools are available that check the conformance of Xml data
  • lots of tools (text editors and the like) support Xml
  • lots of libraries (in about every programming language) support Xml

It also have the advantage of precedence, most of the times. When you're already providing web services in Xml, and one asks for a new service... it'll probably be done in Xml because that's what you know.

  • 6
    XML is more readable than binary or position- or comma-delimited data. Commented Mar 23, 2011 at 18:00
  • Only for a naive user. If I have to visually scan a couple hundred records looking for one that's missing some data I'd much rather look for some blank columns in a block of fixed-length records than wade through a morass of elements and attributes looking for an empty tag.
    – TMN
    Commented Mar 23, 2011 at 19:12
  • 1
    @FrustratedWithFormsDesigner: it really depends on the data at hand. Xml embeds the nature of information near the information proper. If you look at functional programming languages you'll see things like (Haskell): data Person = Person { surname :: String, firstName :: String, age :: Int }, if I then see Person "Doe" "John" 42 it is readable too, and avoid a lot of cruft, yet it's closer to comma delimited. Commented Mar 23, 2011 at 21:01
  • 1
    Ok, Your example was easier to read without the markup, but trivial (I'd say less than 8 or 9 data elements) examples can be made to support all forms (except maybe binary). Datafeeds from the mainframe originate as position-delimited strings (and most of it is just numeric codes), and they are much easier to read and debug and manage after being transformed to XML. Like you said, it can depend... Commented Mar 23, 2011 at 21:22
  • @FrustratedWithFormsDesigner: Yes, that's exactly my point :) It depends, but because there's such a rich ecosystem for XML, and because it's easier to only maintain one set of tools/libraries, people usually use XML for everything. Personally, I favor JSon over XML, but once again without indentation, it's messy :p Commented Mar 24, 2011 at 7:12

XML is a poor choice for files which must be maintained by humans. There is no visual separation between the markup and the content, making it hard to read. It is tedious to write correctly without a special-purpose editor. Any error in an XML document is fatal; an XML document cannot be partially processed. When an XML file is invalid, the resulting error message is often unhelpful.

For any file that must be maintained by a human, I would prefer to use any of JSON, YAML, or source code in some interpreted language (Python, Ruby, Groovy, etc.). We have found that a great way to create XML configuration for legacy code is to use the Groovy MarkupBuilder. Another good choice is to create a domain-specific language; this is quite easy to do with Ruby, Groovy, and many other languages.

  • 9
    I think you're missing the point of XML, the markup is content. The purpose of XML is to describe the meaning of your data. For instance, if you have a telephone number, tagging it as a landline number or mobilenumber adds context that other's might use. Or adding a phone tag around text at all for that matter (might make that number callable on a mobile phone). As for your other points I disagree as well. Authoring xml documents is usually pretty straightforward. Error messages are always related to wellformedness and I'll take editing xml by hand over JSON any day
    – Homde
    Commented Mar 24, 2011 at 2:52
  • @konrad your phone example would be valid for HTML.
    – Florian F
    Commented Sep 13, 2014 at 21:49
  • "Any error in an XML document is fatal; an XML document cannot be partially processed." Yes, that's a large par to the point of XML.
    – Andy
    Commented Jul 18, 2017 at 1:20
  • @Andy It's pretty useless if the XML was written by the human and the application just says "wrong!". A human editor needs to know the line where the error was detected. Commented Jul 26, 2017 at 3:15
  • Any number of tools tell you exactly what line and often what character the error is detected on. XML Tools in NotePad++ for example. .Net will tell you exactly where your .config file is wrong too. If you're talking about an API, one of the benefits of XML is that the API developer can also provide an XSD, which besides ensuring valid XML syntax can also tell you if you have any elements that don't belong, if there should only be one of that element, etc. Handwritten json is much easier to screw up.
    – Andy
    Commented Jul 26, 2017 at 21:39

Parsing is relatively easy while being human readable at the same time.

And some nice parsers ( Eg Xerces {c++} ) are readily available.

  • 2
    Well, it's easy as long as the documents are small. If you have to parse documents too large to reasonably fit into memory, then things get grim.
    – TMN
    Commented Mar 23, 2011 at 19:01
  • I'd question the human readability part. It just takes way too much effort to read XML over reading an equivalent JSON. Commented Mar 27, 2019 at 7:17