XML Still Matters in 2026 (Here's Where and Why)

JSON won the wire format war years ago, but XML is still everywhere it actually mattered: documents, finance, government, SOAP, RSS, SVG. Here's the modern map.

Mian Ali Khalid · 2026-05-04 · 10 min read

Use the tool

XML Formatter

Format, validate, and beautify XML documents.

Open XML Formatter →

A junior engineer joins your team and reads a config file ending in .xml. They ask, with genuine confusion: “Wait, people still use XML?” The honest answer is yes. Not for the things JSON replaced — APIs, configs, log lines — but in places where the strengths of XML still hold and the strengths of JSON don’t. This post is the field map: where XML is still alive in 2026, where it isn’t, and why both lists are short.

Is XML still relevant in 2026?

Yes — XML remains the default format for structured documents, financial messaging, government data exchange, RSS/Atom feeds, SVG graphics, SOAP web services, Office Open XML (.docx, .xlsx), and any pipeline involving XSLT transforms or XSD schema validation. JSON dominates new APIs and configs, but XML never went away in the domains where its semantics — namespaces, mixed content, schema-driven validation — actually matter.

What XML does that JSON can’t

JSON has six value types and they map cleanly to most modern programming language primitives. That’s a feature when you’re moving data between services. It becomes a problem when the data is a document.

Things XML expresses natively that JSON does not:

Mixed content. A paragraph with embedded markup, the way HTML works:

<p>The temperature today is <em>unusually</em> mild for May.</p>

JSON’s representation of the same thing is awkward — you end up with arrays of {type: "text"} and {type: "tag"} objects, every renderer reinvents the structure, and round-tripping through it is fragile.

Attributes vs elements. XML distinguishes between an attribute on an element and a child element of the same name. JSON has only keys. The distinction matters for protocols like XMPP, for SVG attributes, for HTML — it’s part of the data model, not decoration.

Namespaces. XML namespaces let you mix vocabularies in one document without collision. A SOAP envelope contains a header from one namespace, a body from another, encryption metadata from a third — and a parser knows which is which. JSON’s flat key model has no equivalent; you bolt on prefix conventions per project and hope the receiver follows the same convention.

Schema validation that scales. XSD (XML Schema Definition) is verbose but powerful: types, constraints, regex patterns, key/keyref relationships, all enforceable at parse time. JSON Schema covers most cases now, but XSD has 25 years of tooling and ecosystem depth — particularly in finance, government, and inter-organizational EDI.

Comments, processing instructions, CDATA. Document-oriented features. JSON has none of them.

If you’re building an API, none of this matters. If you’re building Microsoft Word, all of it matters.

Where XML still wins in 2026

Document formats. Office Open XML (.docx, .xlsx, .pptx) is XML inside a ZIP. OpenDocument is the same idea. Every major word processor and spreadsheet on the planet roundtrips through XML. The reason is mixed content — JSON cannot describe a Word document the way XML can.

Vector graphics. SVG is XML. It’s been XML since 1999 and there’s no replacement. Every browser parses it. Every design tool exports it. Every web-fonts pipeline depends on it.

Syndication. RSS and Atom are XML. Podcasts are RSS. Newsreaders, podcatchers, every “subscribe” link on the internet at scale uses XML. Some startups invented JSON Feed in 2017; it has not displaced RSS.

Financial messaging. ISO 20022, the global standard for financial messaging — bank-to-bank wire transfers, securities settlement, payment initiation — is XML-based. SWIFT migrated to ISO 20022 XML messages over the 2022–2025 window. Every major bank and payment processor speaks XML on its rails.

Government and regulatory data. XBRL (financial reporting) is XML. HL7 v2 and v3 (healthcare) include XML. Tax filings (UK MTD, IRS efile, EU SAF-T) are XML. Public-sector data exchange runs on it because XSD validation is non-negotiable when the consequences of malformed data are legal.

SOAP web services. Yes, SOAP. Enterprise integration, legacy financial APIs, SAP connectors, healthcare middleware. SOAP has WS-Security, WS-AtomicTransaction, WS-ReliableMessaging — features JSON-over-HTTP doesn’t have stand-alone equivalents for. Newer integrations use REST/JSON or gRPC. Older ones (and many newer enterprise ones) still use SOAP.

XSLT transforms. When you have an XML document and need a different XML document or HTML, XSLT does it declaratively. There’s no equivalent in the JSON world. JSONata and JMESPath are query languages, not transformation languages.

Build and config in long-tail tooling. Maven (pom.xml), Ant, NuGet (.nuspec), Android (AndroidManifest.xml, layouts), iOS storyboards, MSBuild. These aren’t going to migrate. Fight your battles elsewhere.

Where XML lost (and isn’t coming back)

Public APIs. REST + JSON won decisively in 2010–2015. Even SOAP holdouts now expose REST/JSON wrappers. New APIs default to JSON, then maybe gRPC.

Mobile apps. JSON is smaller, parses faster, and most clients are JavaScript or Swift/Kotlin where JSON-to-struct mapping is built in. XML parsing on iOS and Android is more verbose and uses more battery.

Hand-written configs. YAML and TOML own this space now. We covered the tradeoffs in YAML vs JSON. XML is too verbose for short configs.

Log lines and event streams. JSON, JSONL, Avro, Protobuf. Never XML. The verbosity is a real cost when you’re writing 10,000 events per second.

Databases. Document stores went JSON-native (MongoDB, CouchDB, SQL Server’s JSON type, Postgres jsonb). XML database support exists but is niche.

XML’s actual problems

Naming the real downsides:

Verbosity. Every value is wrapped in opening and closing tags. A 500-byte JSON payload often becomes 1.5 KB of XML. Network and storage costs.

Whitespace ambiguity. Whitespace inside elements is technically significant but practically inconsistent. <a>foo</a> and <a> foo </a> differ to the spec; many parsers normalize, some don’t. The choice is yours per use, but you must choose.

Namespaces are confusing. They solve a real problem (vocabulary collision) but add cognitive overhead. Teams new to XML often ignore them, then suffer when they need to mix vocabularies.

Mixed content is hard to model in code. Most languages map XML elements to objects nicely until you hit mixed content; then your generated POJOs/struct code gets ugly fast.

Entity expansion attacks. XML’s external entity (XXE) and “billion laughs” attacks are real. Any XML parser exposed to untrusted input must explicitly disable external entities and limit expansion. This is the #1 reason untrusted XML parsing has bitten teams: leaving the defaults on.

Working with XML in 2026

For reading and exploring an XML document, paste it into the XML Formatter — it pretty-prints, validates well-formedness, and lets you see structure at a glance.

For programmatic use:

Python: lxml (fast, full-featured), xml.etree.ElementTree (built-in, simpler). Always disable external entities for untrusted input — lxml defaults are sane in recent versions, but verify.
JavaScript/Node: fast-xml-parser, @xmldom/xmldom. Browser native DOMParser for client-side.
Go: encoding/xml (built-in, struct-mapped). For namespace-heavy work, look at etree.
Java: JAXB for binding, StAX for streaming, DOM/SAX for the classics. Java’s XML tooling is the deepest of any language.
Rust: quick-xml for streaming, serde_xml_rs for binding-style.

For converting XML to JSON or vice versa, the round trip is lossy by design. XML attributes, namespaces, mixed content, and processing instructions don’t map cleanly. Conversion tools pick conventions (often @attr for attributes, #text for text nodes) but the result is noisier than either format would naturally produce.

A working principle

XML lost the data interchange war. JSON won. That fight is over.

But XML never lost the document and high-trust messaging wars, because those weren’t actually the same fight. When the document model has mixed content, when validation is legally binding, when namespaces matter — XML is still the right tool, and nothing in the JSON ecosystem replaces it.

The mistake is treating “XML or JSON?” as a single question. It’s two: “Is this data?” (use JSON) or “Is this a document?” (probably XML). When you’re in doubt, ask: would I rather hand-edit this in a code editor as JSON, or open it in a structured-document editor with schema autocomplete? That’s the format you actually want.

Related tool