XML vs JSON: differences, and when XML still wins

JSON won. For APIs, configuration, and data interchange between modern services, JSON is the default and has been for over a decade. But XML is far from dead: it still underpins RSS feeds, sitemaps, SVG, Android layouts, Maven builds, SOAP services in enterprise systems, and most document formats. Knowing when each fits, and how to translate between their models, is still a working skill.

If you are staring at either format right now, the XML Formatter and JSON Formatter both run entirely in your browser.

The same data in both formats

<user id="42">
  <name>Ada Lovelace</name>
  <email>ada@example.com</email>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
</user>

{
  "id": 42,
  "name": "Ada Lovelace",
  "email": "ada@example.com",
  "roles": ["admin", "editor"]
}

The JSON version is shorter, and more importantly it maps directly onto the data structures every programming language already has: objects, arrays, strings, numbers, booleans, null. The XML version needs decisions that JSON never asks: is id an attribute or a child element? Is roles a wrapper element or repeated elements? Different producers answer differently, which is why generic XML to JSON conversion is always a little lossy or a little ugly.

The core differences

Two of these differences explain most real world friction.

Types. In XML, <count>3</count> is the text "3". Whether it is a number is a decision the consumer makes, ideally guided by a schema. JSON writes "count": 3 and the type travels with the data. This alone removes an entire class of interchange bugs.

Arrays. XML has no way to say "this is a list". A parser seeing one <role> element cannot know whether more were possible. This is the classic breakage in XML to JSON conversion: a list with one item converts to an object instead of a single element array, and code expecting an array crashes on the day the list happens to have one entry.

What does XML have that JSON lacks?

XML is a document markup language that got used for data; JSON is a data notation. XML's document heritage gives it real capabilities:

• Mixed content. <p>This is <b>bold</b> text</p> interleaves text and markup naturally. JSON has no reasonable representation for this, which is why HTML, SVG, and document formats are XML shaped and always will be.
• Attributes vs content. Metadata about a value can live on the element itself.
• Namespaces. Two vocabularies can coexist in one document without name collisions. Essential for formats like SVG embedded in XHTML, or SOAP envelopes wrapping arbitrary payloads.
• Mature validation. An XSD schema can express types, ranges, ordering, and cardinality, and enterprise tooling around it is deep. JSON Schema has closed most of this gap but arrived fifteen years later.
• Comments. XML allows them. JSON famously does not, a persistent annoyance for configuration files that pushed many projects to YAML or TOML instead.

When should you use XML, and when JSON?

Choose JSON when:

• Building or consuming a web API
• The data is structured records: objects, lists, values
• JavaScript is anywhere in the pipeline
• Payload size and parse speed matter
• You want the format every modern tool speaks by default

Choose XML when:

• The format is already defined as XML: RSS and Atom, sitemaps, SVG, SOAP, Android resources, Office documents
• You need mixed content, real markup within text
• You need namespaces to combine vocabularies
• Your integration partner is an enterprise system that speaks XML, which in banking, insurance, healthcare, and government is still common

Notice the XML list is mostly "the ecosystem already decided". Very few new formats choose XML today, but an enormous installed base guarantees you will keep meeting it.

A note on security

XML's power carries attack surface that JSON simply does not have. Document type definitions can define entities that expand recursively (the "billion laughs" denial of service) or reference external files and URLs (XXE, external entity injection, which can read server files or make server side requests). Every serious XML parser now ships with external entities disabled, but if you accept XML from untrusted sources, verify that yours does. JSON parsing has no equivalent risk: the worst malformed JSON can do is fail to parse.

Converting between them

Because the models differ, conversion needs decisions, not just mechanics: attributes versus elements, single items versus arrays, text nodes versus values. For structured data records the mapping is usually clean. For document shaped XML with mixed content, there is no good JSON equivalent, and forcing one produces something neither format does well.

For inspecting either format, the XML Formatter pretty prints and validates XML, and the JSON Formatter does the same for JSON, both entirely client side, so feeds, configs, and API payloads never leave your machine.