XML in 2026: Is It Still Relevant for Modern Development?

I'll be honest — when I see "XML" in 2026, my first instinct is to think "legacy code." But that's actually unfair. XML is quietly powering some of the most critical systems on the planet, and it's not going away anytime soon. Let me show you why.

Where XML Still Runs the Show

Banking and finance: Every time you make a bank transfer in Europe, there's a good chance it goes through ISO 20022 messages — which are XML. Financial reporting uses XBRL (also XML). We're talking about trillions of dollars flowing through XML pipes every single day.

Healthcare: HL7 FHIR uses both JSON and XML, but the older HL7 v2/v3 messages that most hospital systems run on? Pure XML. Patient records, lab results, prescriptions — all XML.

Your Office documents: Every .docx, .xlsx, and .pptx file is actually a ZIP archive full of XML files. Open one up sometime — it's fascinating (and a bit terrifying).

Android development: Every layout file in Android is XML. activity_main.xml is probably the first file every Android developer creates.

Build tools: Maven's pom.xml, .NET .csproj files, Spring Framework configs — XML is deeply embedded in enterprise toolchains.

What XML Can Do That JSON Can't

Namespaces: Imagine combining elements from different vocabularies in one document without naming collisions. XML namespaces make this possible. It's essential for formats like SVG embedded in HTML, or mixing SOAP headers with custom payloads.

Mixed content: Try representing a paragraph where some words are bold and others are italic in JSON. It's awkward at best. XML handles this naturally because it was designed for documents, not just data.

XSLT transformations: You can write a single XSLT stylesheet that transforms XML into HTML, PDF, another XML format, or plain text. It's a declarative transformation language with no real equivalent in the JSON world.

Schema validation: XML Schema (XSD) is more expressive than JSON Schema in many areas. It can enforce element ordering, complex type hierarchies, and cross-field constraints that JSON Schema struggles with.

A Real-World Example

Let's say you're building an e-commerce system that needs to generate invoices. With XML + XSLT, you store invoice data in XML, then apply different XSLT stylesheets to generate: an HTML version for the browser, a PDF version for printing, and an EDI version for the supplier's system — all from the same source data. Try doing that with JSON.

XML Namespaces in Action

Namespaces are one of those XML features that seem confusing until you actually need them. Here's a practical example — an SVG icon embedded inside an XHTML document:

Without namespaces, the parser wouldn't know whether belongs to the HTML vocabulary or the SVG vocabulary. Namespaces let you mix vocabularies freely in a single document, and that's something JSON simply has no mechanism for.

Common Mistakes Developers Make with XML

After years of working with XML in production systems, here are the pitfalls I see most often:

1. Ignoring encoding declarations. If your XML file contains non-ASCII characters but you forget the encoding declaration, parsers will assume UTF-8 or whatever their default is. Always declare it explicitly:

2. Using attributes when elements make more sense. Attributes can't hold complex structures, can't repeat, and can't easily evolve. If a value might grow in complexity later, use a child element instead.

3. Not validating against a schema. Passing around unvalidated XML is a recipe for silent failures. If you have an XSD, use it. It catches data issues at parse time rather than letting bad data cascade through your system.

4. Building XML by string concatenation. Never do this — it's an injection vulnerability waiting to happen. Always use a proper XML library or DOM builder.

Performance Tips for XML Processing

XML parsers come in two main flavors, and picking the right one matters a lot for performance:

• DOM parsers load the entire document into memory as a tree. Great for small-to-medium documents where you need random access. Bad for large files — a 100MB XML file can consume 1GB+ of RAM as a DOM tree.
• SAX/StAX parsers process the document as a stream, one element at a time. They use almost no memory and are much faster for large files. The trade-off is that you can't jump around in the document.

Here's the rule of thumb: if your XML is under 10MB, DOM is fine. Over 10MB, strongly consider streaming. Over 100MB, streaming is mandatory unless you enjoy watching your server run out of memory.

XML vs JSON: A Quick Reference

A Brief History of XML

XML was published as a W3C recommendation in February 1998. It was designed as a simplified subset of SGML (Standard Generalized Markup Language), which had been around since the 1980s but was notoriously complex. The goal was to create a format that was both human-readable and machine-parseable, strict enough to avoid ambiguity, and flexible enough for any domain. For the first decade of the 2000s, XML was *the* data interchange format. SOAP web services, RSS feeds, Atom feeds, XHTML — everything was XML. Then JSON arrived and took over the web API space, but XML held onto every domain where its unique features (namespaces, schemas, transformations) actually matter.

The Modern XML Developer

Most developers today work in hybrid environments. They use JSON for web APIs and real-time communication, and XML for document processing, enterprise integration, and regulatory compliance. Knowing both formats — and when to use each — is a genuinely valuable skill.

XML Security: XXE and Other Pitfalls

If there's one thing about XML that keeps security engineers up at night, it's XXE — XML External Entity attacks. And honestly, it should concern you too. XXE has been on the OWASP Top 10 list for good reason, and it's still catching developers off guard in 2026.

Here's how XXE works: XML allows you to define "entities" — essentially variables — in the document type declaration (DTD). An *external* entity can reference a URL or a file path on the server. If the parser is configured to resolve external entities (many are by default), an attacker can craft XML that reads arbitrary files from your server:

When the parser processes this, it replaces &xxe; with the contents of /etc/passwd. Just like that, an attacker reads sensitive files from your system. In more advanced attacks, they can even make outbound HTTP requests from your server (Server-Side Request Forgery), or cause denial of service with the infamous "billion laughs" attack — a recursive entity expansion that consumes all available memory.

The fix is straightforward: disable external entity processing. Here's how in two popular languages:

Beyond XXE, watch out for XML injection — where user input is inserted into XML without proper escaping. It's the XML equivalent of SQL injection. Always use a proper XML builder library instead of string concatenation (which I mentioned in the common mistakes section, but it's worth repeating because it's *that* important).

The golden rule: never parse untrusted XML with default parser settings. Always explicitly disable external entity resolution, DTD processing, and XInclude processing. Treat XML from the outside world with the same suspicion you'd treat user input in a SQL query.

XPath: Querying XML Like a Pro

If you work with XML regularly and you're not using XPath, you're doing it the hard way. XPath is a query language specifically designed for navigating XML documents, and it's incredibly powerful once you get the hang of it.

Think of XPath like CSS selectors but for XML. Instead of traversing the DOM manually with nested loops, you write a concise expression that selects exactly the nodes you want. Here are some practical examples:

Here's how you use XPath in JavaScript and Python — the two languages most developers reach for:

One thing worth noting: JSON has no built-in query language. The closest equivalent is jq, which is fantastic but is an external tool rather than a standardized part of the format. XPath is baked into the XML ecosystem — supported by browsers natively, available in virtually every programming language, and standardized by the W3C. It's one of XML's genuine competitive advantages.

XPath also forms the foundation for XSLT (which selects nodes to transform) and XQuery (a full query language for XML databases). Once you learn XPath, you've unlocked a whole family of XML technologies.

XML in Industry-Specific Standards

I mentioned banking and healthcare earlier, but XML's reach into industry-specific standards goes much deeper than that. Here's a tour of domains where XML isn't just used — it's *required*:

Legal: The legal industry relies heavily on XML for court filing and case management. LegalXML, developed by OASIS, standardizes electronic court filing, legal citations, and case metadata. In the US, many state court systems mandate XML-based e-filing formats. If you're building legal tech, you're building on XML.

Publishing: Here's one that surprises people — every EPUB ebook you've ever read is built on XML. EPUB files are ZIP archives containing XHTML content files (which are XML), an OPF package descriptor (XML), and a navigation document (XML). DocBook, another XML format, has been the standard for technical documentation since the 1990s. O'Reilly Media famously used DocBook for years to produce their books in multiple output formats from a single XML source.

Science and Mathematics: MathML is the W3C standard for representing mathematical notation in XML. It's supported by all modern browsers and is essential for scientific publishing on the web. Then there's Chemical Markup Language (CML) for molecular structures, Astronomical Markup Language for stellar data, and dozens of other scientific XML vocabularies. When precision and unambiguous data representation matter — and in science, they always do — XML delivers.

Government and Procurement: Universal Business Language (UBL) is an OASIS standard used by governments worldwide for procurement, invoicing, and supply chain management. The European Union's e-invoicing directive essentially mandates UBL-based XML for business-to-government invoicing. If you sell to European governments, you're sending XML invoices.

Aviation: Aeronautical Information Exchange Model (AIXM) defines XML schemas for aeronautical data — airports, airspaces, navigation aids, procedures. Every flight management system, every air traffic control update, every NOTAM (Notice to Airmen) touches AIXM data. This is one domain where "let's just switch to JSON" isn't a conversation anyone is having, because the safety implications of a format migration would be enormous.

The common thread across all these industries? They chose XML because they needed strong validation, namespaces for combining vocabularies, and a format that could evolve over decades without breaking backward compatibility. Those requirements haven't changed.

SOAP vs REST: Why XML APIs Still Exist

If you started your career in the last decade, you might think all APIs are REST with JSON. But walk into any large bank, insurance company, telecom, or government agency, and you'll find SOAP web services handling critical business logic. And there are actually good reasons for that.

SOAP (Simple Object Access Protocol) is an XML-based messaging protocol with some features that REST+JSON simply doesn't offer out of the box:

Strong contracts via WSDL: A WSDL (Web Services Description Language) file describes *everything* about a SOAP service — operations, input/output message structures, data types, endpoints. You can auto-generate client code from a WSDL in Java, C#, Python, or virtually any enterprise language. REST APIs have OpenAPI/Swagger, but adoption is voluntary. With SOAP, the contract is the service.

Built-in error handling: SOAP has a standardized fault element with fault codes, fault strings, and detail elements. Every SOAP client knows exactly how to parse errors. REST APIs? Every API invents its own error format.

WS-Security: SOAP has a comprehensive security standard that supports message-level encryption and signing — not just transport-level (TLS). This means a SOAP message can pass through intermediary servers while remaining encrypted end-to-end. This matters a lot in financial services where messages route through multiple systems.

Transactions and reliability: WS-AtomicTransaction and WS-ReliableMessaging provide distributed transaction support and guaranteed delivery. These are hard problems that REST leaves entirely to the application developer.

That said, SOAP has real drawbacks: the messages are verbose, the learning curve is steep, debugging is painful, and the XML overhead makes it slower than JSON for simple CRUD operations. For new web APIs and microservices, REST+JSON is almost always the right choice. But for complex enterprise integrations — especially in regulated industries — SOAP's built-in contract enforcement and security features remain genuinely valuable.

Migrating from XML to JSON: A Practical Guide

At some point in your career, someone will ask you to migrate an XML-based system to JSON. Before you say "sure, easy," let me walk you through the pitfalls that catch everyone by surprise.

Attribute loss: XML elements can have both attributes and child elements. JSON objects only have properties. When converting Dune, where does id go? Where does format go? Where does the text content go? Common conventions use @ prefixes for attributes and #text for text content, but there's no universal standard — and whatever you choose, the other system needs to understand your convention.

Type coercion: XML is inherently text-based. The string "42" in XML might be an integer, a float, a string, or a zip code. JSON has distinct types. During migration, you need explicit type mapping rules, or you'll end up with strings where you wanted numbers (or worse, numbers where you wanted strings — goodbye leading zeros in zip codes).

Array ambiguity: This one is particularly nasty. In XML, if an element has one child, it's a single element. If it has multiple children with the same name, they're naturally a collection. But JSON needs to know upfront whether something is an array or a single value. Consider: Widget — is item a string or a single-element array? If another order has three items, the structure changes. Your JSON consumer needs to handle both cases.

Steps for a successful migration:

• Step 1: Inventory all XML schemas and document exactly which features you're using (namespaces, attributes, mixed content, CDATA sections, processing instructions).
• Step 2: Design your JSON schema first, explicitly deciding how to handle attributes, mixed content, and arrays. Document every decision.
• Step 3: Build a conversion layer (not a big-bang rewrite). Run both formats in parallel and compare outputs.
• Step 4: Migrate consumers one at a time, keeping the XML endpoints alive until everyone has switched.
• Step 5: Run parallel systems for at least one full business cycle (month, quarter, or year depending on your domain) before decommissioning XML.

When NOT to migrate: If your XML uses heavy namespace mixing, XSLT transformations, or XPath-based business rules, the migration cost may outweigh the benefits. Also, if your XML is mandated by a regulatory standard (HL7, ISO 20022, UBL), you'll be maintaining XML regardless — adding JSON just adds a second format to support.

XML Tools Every Developer Should Know

Working with XML doesn't have to be painful if you have the right tools in your belt. Here are the ones I rely on:

xmllint: Ships with libxml2 and is probably already on your system. It validates XML against schemas, formats (pretty-prints) XML, and evaluates XPath expressions — all from the command line. It's the curl of the XML world: simple, fast, and everywhere.

Saxon: The gold standard XSLT and XQuery processor, developed by Michael Kay (who literally edited the XSLT 2.0 and 3.0 specs). If you're doing serious XSLT transformations, Saxon is what you want. The open-source Home Edition handles XSLT 3.0 and XPath 3.1.

XMLSpy (Altova): A commercial XML IDE that's popular in enterprises. It has visual schema editors, XSLT debuggers, and database integration. It's expensive but powerful — particularly useful when you're working with massive XSD schemas that are impractical to edit by hand.

oXygen XML Editor: My personal favorite for XML-heavy work. It supports XSLT debugging with step-through execution, XPath evaluation, schema-aware editing with auto-complete, and has excellent DITA and DocBook support. If you write XSLT regularly, oXygen pays for itself in a week.

xmlstarlet: A command-line XML toolkit that lets you query, edit, validate, and transform XML right from the terminal. Think of it as sed and awk but for XML. It's perfect for shell scripts and CI/CD pipelines where you need to extract values from XML config files or modify XML on the fly.

Visual Studio Code with XML extensions: If you're already in VS Code, the "XML" extension by Red Hat gives you schema validation, auto-completion, and formatting. Combined with the "XSLT/XPath" extension, it's a surprisingly capable free setup for occasional XML work.

Try It Yourself

Need to bridge the two worlds? Our XML to JSON Converter handles the transformation while preserving data structure and types, and our online JSON formatter pretty-prints the result so you can check it converted the way you expected. If you're debugging XML, the XML Formatter makes even the ugliest XML readable. And before deploying any XML to production, run it through the XML Validator to catch structural issues early.