XML vs JSON: Where XML Still Wins

JSON won the web API. That does not make XML obsolete, and knowing where it is still the right answer saves you from reimplementing features it already has.

The same data in both#

<order id="1001" currency="GBP">
  <customer>Ada Lovelace</customer>
  <items>
    <item sku="A-1" qty="2">Widget</item>
  </items>
</order>

{
  "id": "1001",
  "currency": "GBP",
  "customer": "Ada Lovelace",
  "items": [{ "sku": "A-1", "qty": 2, "name": "Widget" }]
}

JSON is shorter and maps directly onto native data structures in every modern language. That is the entire reason it won, and for most APIs it is decisive.

Where XML is genuinely better#

Mixed content. Text with inline markup is XML's native shape:

<p>See the <link href="/docs">documentation</link> for details.</p>

JSON has no good representation for this. You end up with an array of alternating text and object nodes — which is exactly what every rich-text JSON format does, and it is strictly worse to read and write than the XML.

The attribute/element distinction. XML lets you separate metadata from content. JSON has one kind of key, so "id" and "customer" look identical structurally even though one identifies and one describes.

Namespaces. XML can merge vocabularies from different sources in one document without collision. JSON has no mechanism for this; JSON-LD bolts one on with @context precisely because the need is real.

Schema validation and transformation as standards. XSD is more expressive than JSON Schema — ordering, occurrence constraints, substitution groups — and XSLT is a standardised, declarative document transformer with no equivalent in the JSON world. If you genuinely need to transform document structure declaratively, XSLT is a mature answer.

Comments. XML has them. JSON does not.

Where XML is worse#

• Verbosity. Closing tags roughly double the size before compression.
• Parsing ergonomics. There is no canonical XML-to-object mapping, so every library invents one — and they disagree about attributes, repeated elements and whitespace.
• Lossy round-trips. Many XML-to-object libraries collapse repeated sibling elements into arrays and lose document order, so parse-then-serialise produces a different document. If you are writing an XML formatter, order preservation is mandatory.
• Security surface. XML has features JSON lacks that are actively dangerous: external entity expansion (XXE) can read local files, and the "billion laughs" entity expansion attack is a denial of service. Both must be explicitly disabled in most parsers.

// XXE: disable entity processing on untrusted input
const parser = new XMLParser({ processEntities: false });

Where you will still meet XML#

• SOAP APIs in banking, insurance, healthcare, logistics and government.
• RSS and Atom feeds — including the one on this blog.
• Sitemaps. sitemap.xml is XML by specification.
• Document formats. SVG, .docx, .xlsx and EPUB are all XML underneath.
• Config in the JVM and .NET worlds. Maven, Spring, MSBuild.
• Industry data standards. FHIR, HL7, ONIX, FpML.

A decision rule#

• API payloads between services you control → JSON
• Documents with inline markup → XML
• You need declarative transformation or expressive schema validation → XML
• Integrating with an existing XML system → XML, and do not fight it
• Anything consumed by browser JavaScript → JSON

Frequently asked questions#

Is XML slower to parse?#

Yes, meaningfully — the grammar is larger and documents are bigger. It rarely matters at low volume and matters a lot at high volume.

Can I convert XML to JSON losslessly?#

Not in general. Attributes, namespaces, comments, processing instructions and mixed content have no natural JSON equivalent. Conventions exist (prefixing attributes with @) but they are conventions, not standards.

What about Protocol Buffers or MessagePack?#

Better than both for high-volume machine-to-machine traffic: smaller, faster, schema-enforced. They are not human-readable, which is why JSON still dominates public APIs.

Is JSON always smaller after compression?#

Usually, but the gap narrows a lot — gzip handles XML's repeated closing tags very well. The raw-size argument is weaker than it looks over HTTP.

Related reading#

• JSON vs YAML vs TOML
• JSON Schema Validation
• Format either with the XML Formatter or the JSON Formatter.

References#

• W3C: XML 1.0 specification
• OWASP: XML External Entity Prevention