Back to Blog
Industry Insights 10 min read February 10, 2026

XML in 2026: Dead? No — It's Everywhere You're Not Looking

Developers have been declaring XML dead since JSON arrived. But XML quietly runs RSS feeds, SVG graphics, SOAP APIs, Android layouts, Office documents, and sitemaps. Here's why XML literacy still matters.

DevForge Team

DevForge Team

AI Development Educators

Code editor showing structured markup and data format files

The Premature Death of XML

Every few years, a new article declares XML dead. JSON killed it. YAML replaced it. Protocol Buffers are faster. GraphQL made it obsolete.

And yet: every time you open a Word document, every time an Android app renders a layout, every time your podcast appears in Apple Podcasts, every time your website's sitemap gets crawled by Google, every time a legacy enterprise system sends an invoice — XML is doing the work.

XML isn't dead. It's infrastructure. And like all infrastructure, it's invisible until you need to debug it, extend it, or integrate with it.

This article is the case for XML literacy in 2026: not to advocate for XML over JSON, but to make the argument that developers who don't understand XML are flying blind in a surprising number of real-world contexts.

Where XML Actually Lives in 2026

SVG: The Vector Graphics Standard

Every SVG file is XML. When you write:

xml
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
  <circle cx="50" cy="50" r="40" fill="#E97627" />
  <text x="50" y="55" text-anchor="middle" fill="white" font-size="20">XML</text>
</svg>

You're writing XML. Every <path>, <rect>, <g>, and <use> element follows XML rules: namespaces, well-formedness, attribute quoting. SVG is so deeply embedded in modern web development that developers use XML daily without recognizing it.

Understanding XML namespaces explains why xmlns="http://www.w3.org/2000/svg" is necessary. Understanding well-formedness explains why <br> is invalid in SVG but <br /> is not. The XML foundation makes SVG's behavior predictable.

RSS and Atom: Podcast and Feed Infrastructure

Every podcast feed is an RSS document. RSS is XML with a specific vocabulary. When a podcast app subscribes to your show, it's parsing XML. When your blog publishes a feed, it's generating XML.

xml
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd">
  <channel>
    <title>DevForge Podcast</title>
    <link>https://devforgeacademy.com</link>
    <item>
      <title>Episode 42: XML Is Everywhere</title>
      <enclosure url="https://example.com/ep42.mp3" type="audio/mpeg" length="24576000" />
      <itunes:duration>25:30</itunes:duration>
    </item>
  </channel>
</rss>

Notice the xmlns:itunes namespace declaration. Apple's podcast extensions require XML namespaces. Without understanding how namespaces work, debugging a feed that won't validate in Apple Podcasts becomes guesswork.

SOAP: Legacy Enterprise APIs Still Signing Paychecks

JSON REST APIs dominate new development. But an enormous amount of enterprise software — banking systems, insurance platforms, healthcare infrastructure, government services, ERP systems — communicates via SOAP.

SOAP (Simple Object Access Protocol) is XML-based. Every SOAP message is an XML envelope containing a header and body. Every SOAP response is XML. If you need to integrate with a bank's payment API, a hospital's patient records system, or a government tax service, there's a non-trivial chance you're working with SOAP.

xml
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <auth:Credentials xmlns:auth="https://api.example.com/auth">
      <auth:Token>abc123</auth:Token>
    </auth:Credentials>
  </soap:Header>
  <soap:Body>
    <GetCustomerRequest xmlns="https://api.example.com/customers">
      <CustomerId>12345</CustomerId>
    </GetCustomerRequest>
  </soap:Body>
</soap:Envelope>

Without XML fluency, reading a WSDL (Web Services Description Language) document — which defines what a SOAP service can do — is nearly impossible.

Android Layouts: XML-Driven UIs

Android's native UI framework is XML-based. Every layout file in an Android project is XML:

xml
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <TextView
        android:id="@+id/title"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/app_title" />

</LinearLayout>

Android's namespace (xmlns:android="http://schemas.android.com/apk/res/android") is XML namespace syntax. The constraint of attribute values needing quotation marks is an XML rule. The tree structure of nested layouts is XML's document object model.

Jetpack Compose has shifted Android development toward Kotlin-based declarative UI, but XML layouts remain common in existing codebases and some tooling.

Office Open XML: Every .docx and .xlsx File

Microsoft's Office formats (Word, Excel, PowerPoint) are ZIP archives containing XML files. A .docx file is a ZIP with:

  • word/document.xml — the document content
  • word/styles.xml — style definitions
  • [Content_Types].xml — MIME type declarations

When you use a library like python-docx, openpyxl, or Apache POI to generate reports programmatically, you're generating Office Open XML. When you parse an uploaded Excel file, you're ultimately parsing XML.

Sitemaps: SEO Infrastructure

Google and other search engines use XML sitemaps. Every sitemap is XML:

xml
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://devforgeacademy.com/tutorials/xml-fundamentals</loc>
    <lastmod>2026-02-10</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

Generating sitemaps for large sites, validating them, and debugging why Google Search Console rejects a sitemap — all of this requires XML literacy.

Maven and Gradle: Java Build Configuration

Maven build files (pom.xml) are XML. Every Java project using Maven has an XML configuration file that defines dependencies, plugins, and build lifecycle. Spring Boot projects, Android Studio projects, and enterprise Java applications all use XML configuration extensively.

Why JSON Didn't Kill XML

JSON replaced XML for a specific use case: lightweight data exchange between web clients and servers. In that context, JSON is genuinely better — more concise, native to JavaScript, easier to read for simple data structures.

But the comparison misses the point. XML and JSON serve different needs:

XML excels at:

  • Document-centric content with mixed content (text interspersed with markup)
  • Data that requires schema validation with complex constraints
  • Formats that need transformation (XSLT)
  • Querying complex nested structures (XPath)
  • Formats requiring comments
  • Namespace-based extensibility (multiple vocabularies in one document)

JSON excels at:

  • Simple data serialization
  • Browser/JavaScript interoperability
  • Readability for flat or lightly nested data
  • Streaming large arrays

SVG works as XML because it's document-centric with complex element hierarchies and transformation requirements. An RSS feed works as XML because it has Dublin Core and iTunes extension vocabularies merged via namespaces. A REST API response works as JSON because it's simple key-value data going to a JavaScript client.

The right tool for each job hasn't changed.

The Developer Who Doesn't Know XML

Consider what happens to an XML-illiterate developer in real scenarios:

Scenario 1: A podcast feed isn't appearing in Spotify. The feed validator shows a namespace error. The developer doesn't understand what xmlns:itunes means or why the iTunes namespace URI must be exact. Debugging takes 4 hours instead of 20 minutes.

Scenario 2: An SVG icon isn't rendering correctly in a React component. The issue is a missing namespace declaration. The developer spends time on CSS fixes instead of diagnosing the root XML problem.

Scenario 3: Integrating with a bank's SOAP API. The WSDL is impenetrable. The developer can't figure out the namespace structure of the request envelope. The integration project gets delayed.

Scenario 4: Generating Excel reports with openpyxl. The generated file has formatting issues. The developer can't inspect the XML inside the .xlsx to understand what went wrong.

XML literacy turns all four scenarios from multi-hour debugging sessions into quick diagnoses.

What XML Literacy Actually Requires

You don't need to be an XML expert. You need a working foundation:

Well-Formedness

Every XML document must be well-formed: all tags closed, attributes quoted, a single root element, proper character encoding. This is the minimum. If your XML isn't well-formed, nothing will parse it.

Namespaces

Namespaces allow multiple vocabularies to coexist in one document without name collisions. Understanding why xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" declares a namespace prefix and how to use it (<itunes:duration>) is essential for any multi-vocabulary XML format.

XPath

XPath is the query language for XML. When you use Selenium for browser testing, driver.find_element(By.XPATH, "//div[@class='title']") is XPath. When you use Python's lxml library to extract data from XML, you write XPath expressions. When you debug XSLT stylesheets, you use XPath. A day spent learning XPath syntax pays dividends across testing, data extraction, and transformation work.

Schema Validation (XSD)

XSD defines what's valid in an XML document. When integrating with a SOAP service, the WSDL references XSD schemas that define the exact structure of request and response messages. Understanding how to read XSD data types (xs:string, xs:decimal, xs:date) and facets (xs:minLength, xs:pattern) makes WSDL documents readable.

The Learning Path

The XML Fundamentals tutorial on DevForge covers the complete foundation: syntax and well-formedness, DTD and XSD validation, namespaces, XPath querying, XSLT transformation, and real-world applications.

The tutorial is structured so developers can apply each concept immediately. By the end of the XPath lesson, you can write selectors that extract data from any XML document. By the end of the XSLT lesson, you can transform one XML vocabulary into another.

Conclusion

XML is infrastructure — invisible when it works, expensive to debug when you don't understand it. Every developer who works with SVG, feeds, SOAP APIs, Office documents, Android layouts, sitemaps, or Maven is working with XML regularly.

The developers who invested in XML literacy 10 years ago aren't struggling with these debugging sessions. The developers who wrote XML off as legacy are the ones spending hours on problems that a solid understanding of namespaces would resolve in minutes.

In 2026, XML literacy isn't about choosing XML over JSON. It's about having the complete toolkit for the actual range of formats and protocols you'll encounter in professional software development.

#XML#Web Development#Data Formats#SVG#SOAP