What is XML and What Are Its Uses?

XML stands for Extensible Markup Language. It lets you define your own tags to describe data, which is the main thing separating it from HTML and its fixed vocabulary.

The World Wide Web Consortium governs the standard, and nearly every programming language ships with a parser that reads it directly, from configuration files to enterprise data feeds.

SOAP, the XML-based protocol for web service messages, ran in 26% of surveyed APIs in 2023, down from 34% the year before, according to Postman’s State of the API Report.

What Is XML

Tags you invent yourself, wrapped around data that another system needs to understand. The “extensible” part of the name is doing all the work here.

A markup language wraps raw text in tags that say what a piece of data is, not how it should look on a screen. HTML arrives with a vocabulary browsers already recognize and rendering rules attached. XML arrives with neither. You write the tag list yourself, shaped around an invoice, a product feed, a build configuration, whatever it is you’re describing.

The syntax comes from an older and much heavier standard, Standard Generalized Markup Language (SGML, formally ISO 8879). XML kept the brackets and threw out most of the complexity.

It gets called a lot of things it isn’t. Not a programming language, since there are no loops, no functions, no logic anywhere in it. Not a database, though databases export to it constantly. And not really a web format, despite the W3C connection. It turns up in desktop software and industrial control systems as often as it does online.

Microsoft’s .docx and .xlsx files are XML under the hood. Open one in a zip tool and you’ll find a folder of XML documents describing every paragraph, cell, and style. That’s the Office Open XML format, and it shows how invisible this stuff usually is. Nobody saving a Word file thinks about markup.

XML Document Structure

One root element at the top, child elements and attributes nested underneath. Every XML file follows that skeleton regardless of what data it holds.

Prolog and XML Declaration

The prolog sits at the very top of the file, usually as a single line called the XML declaration.

A typical one reads <?xml version="1.0" encoding="UTF-8"?>. It names the XML version the document follows, almost always 1.0, and it declares the character encoding so parsers know how to read the bytes. UTF-8, most of the time.

Leave it out and most parsers carry on fine, since 1.0 and UTF-8 are the assumed defaults. Leave it out of a document full of unusual characters, or one saved in a different encoding, and you get a rendering mess quickly.

Root Element and Child Elements

Every well-formed document has exactly one root element. Everything else lives inside it, and child elements can carry their own children as deep as the data requires.

Android’s AndroidManifest.xml is a real example worth looking at. A single root manifest element holds application, activity, and permission elements nested inside it.

Hierarchical data is where this pays off. Orders holding line items, or departments holding teams holding employees. Chapters holding sections holding paragraphs is close to what publishing systems actually do with it.

Attributes and Text Content

Data inside an element can sit in two places: on the opening tag as an attribute, or between the tags as text content.

Neither one is correct in some absolute sense. Convention puts metadata in attributes (an ID, a date, a unit of measure) and the actual value in text content. A product record makes the split easy to see. <product id="4471" currency="USD"> carries the identifiers up top, and <price>29.99</price> carries the number anyone actually cares about.

There’s also the CDATA section for text that shouldn’t be parsed as markup. Useful when you’re stuffing a chunk of HTML or code inside an XML field and don’t fancy escaping every bracket by hand.

XML Syntax Rules for Well-Formed Documents

Break one syntax rule and the parser stops. No partial rendering, no best guess at what you probably meant. HTML is forgiving in a way XML never tries to be, quietly patching missing tags and carrying on.

Not much has changed since 1998. The Fifth Edition of XML 1.0, a W3C Recommendation published 26 November 2008, relaxed which characters are allowed in element and attribute names, which opened things up to a far wider range of Unicode.

Tag and Nesting Rules

Most broken XML files come down to the same handful of things:

• Every opening tag needs a matching closing tag, or a self-closing tag like <br/>
• Tags must nest properly and never overlap
• Exactly one root element wraps the whole document
• Attribute values must sit inside quotes, single or double

Miss a closing tag in an RSS feed and Chrome won’t render it at all. You get a parsing error where the content should be.

Attribute Quoting Rules

Quoting isn’t optional. id=42 fails validation. id="42" and id='42' both pass, and either style works as long as you don’t switch mid-attribute.

Raw ampersands and angle brackets inside text content or attribute values break parsing the same way. Those get swapped for entity reference equivalents.

The ones every XML author runs into:

• Ampersand, written as the amp entity reference
• Less-than sign, written as the lt entity reference
• Double quote sitting inside a double-quoted value, written as the quot entity reference, though you can also sidestep it by switching that one attribute to single quotes

Most teams settle on double quotes across a whole document and stop thinking about it.

Case Sensitivity

<Price> and <price> are two different elements to any parser. XML is case-sensitive top to bottom, which catches out anyone arriving from HTML, where tag case barely registers.

Conventions vary by vocabulary. camelCase runs through Office Open XML and plenty of web service schemas. PascalCase shows up in .NET-generated XML and configuration files. Some publishing formats, DocBook among them, use lowercase with hyphens.

Pick one and hold to it. Switching partway through a document is a reliable way to fail validation.

XML Namespaces

Mix two XML vocabularies in one document and sooner or later they collide. Namespaces fix that by prefixing element and attribute names with a unique identifier, usually a URI.

The World Wide Web Consortium published the Namespaces in XML specification as a Recommendation on 14 January 1999, roughly a year after XML 1.0 itself shipped.

The problem looks like this. A document mixes a company’s own product elements with elements from a shipping vendor’s XML format, and both formats happen to use a <price> tag for completely different things. Without a namespace the parser has no way to tell them apart. With one, each tag carries a prefix, inv:price and ship:price, pointing at the vocabulary it came from.

Default namespaces apply to every unprefixed element in scope and get declared once at the root or on a parent element. Prefixed ones only cover elements carrying that specific prefix, which is what lets several namespaces sit in the same document without stepping on each other.

SVG graphics embedded directly inside an HTML5 page are the case most web people have actually met. The SVG namespace keeps elements like <path> or <circle> from colliding with anything similarly named around them.

XML Validation: DTD vs XML Schema (XSD)

Well-formed and valid are not the same test. Validation checks a document against a predefined structure, so a file with flawless syntax still fails if a required element is missing or a date field holds something that isn’t a date.

DTD and XSD cover most of what you’ll meet in practice, with RELAX NG a distant third.

Document Type Definition (DTD)

DTD came over from SGML and is the oldest of the three. It defines which elements and attributes are allowed and in what order, so it handles element order, required elements, and how many times an element can repeat.

What it can’t touch is data types. A price element can legally hold the text banana and the DTD won’t blink. That single gap is why DTD has faded back to legacy systems and simple internal formats.

XML Schema Definition (XSD)

XSD reached Recommendation status in 2001 with the two things DTD never had, real data types and namespace awareness. W3C finalized the current edition, XSD 1.1, in April 2012, adding features like conditional type assignment on top of the original 1.0 feature set.

Banking leans on it hard. ISO 20022, the global standard for financial messaging, defines its message formats using XSD schemas so banks worldwide validate transactions against the same rules.

RELAX NG still has a following in publishing and document-heavy work, mostly for its simpler and more readable syntax, but it never came close to XSD’s adoption.

How XML Is Parsed: DOM vs SAX

Parsing turns raw XML text into something a program can work with. The two dominant models split on memory.

DOM builds the entire document as a tree in memory. Code can jump to any node, read it, change it, in whatever order it likes. The cost is memory, and it scales badly once files get large.

SAX reads once, top to bottom, firing an event at every tag it passes. Nothing stays stored afterward, so memory usage stays flat no matter how big the file gets. There’s also no going back to a node you’ve already passed.

Apache Xerces and libxml2, two of the most widely used parsing libraries, support both models. The choice usually comes down to file size and what the code needs to do afterward.

DOM Parsing

Document Object Model, published by the W3C as DOM Level 1 on 1 October 1998, less than a year behind XML 1.0 itself.

Most XML editors, browsers, and configuration-file tools default to it. Easier to code against, since the whole tree is sitting there waiting to be queried.

Then someone hands you a 2GB XML export and the parser tries to load all of it into RAM at once. That’s the point where DOM stops being convenient.

SAX Parsing

SAX (Simple API for XML) never became an official W3C standard, unlike DOM. It grew out of the XML developer community and turned into a de facto one anyway.

Python’s xml.sax module and Java’s SAXParser both implement this model directly, and both get used constantly for streaming large log files, feeds, and exports.

Multi-gigabyte exports suit it. So do one-pass validation or extraction jobs. Anything that needs to edit the document, jump backward, or query it more than once does not, and no amount of clever code gets around that.

XML and Related Technologies

XML rarely works alone. A small group of companion technologies transform it, query it, or wrap it for transport between systems.

XSLT

XSLT (Extensible Stylesheet Language Transformations) takes an XML document and rewrites it into something else, usually HTML for display or a different XML schema for a system that expects a different shape.

XSLT 1.0 and XPath 1.0 both became W3C Recommendations on 16 November 1999. XSLT has since grown into its current 3.0 edition.

Saxon, built by Saxonica, is the best-known processor and supports the full 3.0 spec. That includes streaming very large documents through a transform without loading them entirely into memory.

Publishing pipelines live on this. DocBook-based documentation systems turn one source XML file into a PDF manual, an HTML help site, and an EPUB, all from the same file.

XPath

XSLT and XQuery both depend on XPath to say which part of a document they’re pointing at. The syntax looks like a file system path. Something like /catalog/product[3]/price selects the price element inside the third product in a catalog document.

Strip XPath out and neither of the other two has any way to address anything.

XQuery

XQuery does for XML what SQL does for relational tables, except it searches XML data rather than rows. It can pull matching nodes from a single document or join data across several XML sources in one query.

Native XML databases like MarkLogic and BaseX use it as their primary query language, the same way a relational database leans on SQL.

SOAP messaging, common in older enterprise web services, wraps requests and responses in an XML envelope, exposing functionality as a callable API that other systems reach over HTTP.

What XML Is Used For

XML turns up wherever data has to move between systems that share no codebase, no database, and no programming language in common. Content syndication, enterprise messaging, office file formats, and application configuration cover most of where it still lives.

Data Feeds and Syndication

RSS and Atom are the two XML-based formats behind web feeds.

RSS got there first and fragmented almost immediately. RSS 0.91 was the original simplified format, RSS 1.0 got rebuilt around RDF, and RSS 2.0 is what most feeds use today. Three incompatible things sharing one name.

Atom arrived afterward specifically to clean that up with one clear specification. The IETF published the Atom Syndication Format as RFC 4287 in December 2005, built on well-formed XML instead of RSS’s looser, more permissive rules.

Podcasting still runs almost entirely on this plumbing. Apple Podcasts, Spotify, and most other podcast apps pull new episodes from an RSS feed attached to the show.

Web Services

SOAP is the clearest case of XML doing heavy lifting out of sight.

Airline reservations are a good example. Large parts of the SABRE and Amadeus global distribution systems, the backbone booking engines behind most travel agency software, still run core integrations over SOAP. WSDL (Web Services Description Language) describes what a SOAP service offers and how to call it, written in the same XML-based family as SOAP itself.

Newer systems mostly reach for JSON-based REST instead. SOAP hasn’t gone anywhere though, and it’s still normal in banking and payment processing, healthcare data exchange, and travel booking, which is to say the industries where ripping out a working integration is nobody’s idea of a good quarter.

Document and Configuration Formats

Two office suites, two XML formats. Microsoft’s Office Open XML gives you .docx, .xlsx, and .pptx. The OpenDocument Format behind LibreOffice and OpenOffice gives you .odt, .ods, and .odp. ISO and IEC approved Office Open XML as an international standard, ISO/IEC 29500, published in November 2008.

Configuration is the other half, though that territory keeps shrinking. Java’s Maven build tool reads project settings from pom.xml. Older .NET applications still store theirs in web.config.

Newer tools go for YAML or TOML, both lighter to type and easier to read at a glance. XML configuration sticks around in large, established codebases that predate the shift, and honestly there’s rarely a good reason to migrate one that works.

XML vs HTML

Same brackets, same SGML lineage, different jobs. HTML describes how content should look and behave in a browser. XML says what the content means and holds no opinion at all about display.

XHTML sits right on the line between them, HTML’s own vocabulary rewritten to obey XML’s strict well-formedness rules. Every tag closed, every attribute quoted, nesting enforced throughout.

Where the two really part ways is in how they react to broken markup. A browser patches over a missing closing tag and keeps rendering. An XML parser stops cold and throws an error, however trivial the mistake.

That’s why XHTML never replaced ordinary HTML for everyday pages. Strict validation is a feature when you’re exchanging data between systems and a liability when someone is hand-editing a blog post at 11pm.

Use HTML when the output is a page a browser renders. Use a custom XML vocabulary when the output is data a program has to parse, validate, and hand on unchanged.

XML vs JSON

JSON reads and writes faster in most programming languages because it maps straight onto native objects and arrays with no translation step in between.

XML carries structure JSON has no equivalent for. Attributes, namespaces, mixed content, comments.

Amazon S3’s REST API is still standing on the XML side. Many of its core operations return XML by default, even though most newer AWS services default to JSON.

When XML Fits Better

Mixed content is the big one, text with markup running through it, which JSON can’t represent cleanly without ugly workarounds. Schema validation through DTD or XSD catches structural errors before any code runs. Namespaces let different vocabularies share a document without collision. And regulated industries have decades of XML-based data contracts already in place, which counts for more in practice than any technical argument.

The downsides are real. XML is verbose, since every value needs an opening and a closing tag, so the same data takes more bytes than the JSON version. It also parses slower in most modern runtimes, which have been optimized around JSON for years now.

Document-centric data favors it anyway. A legal contract or a formatted book chapter is mixed content by nature, and that’s the shape XML was built for.

When JSON Fits Better

For most new API work JSON wins outright. It maps directly onto objects and arrays in JavaScript, Python, and nearly every modern language. Payloads come out smaller with no closing tag overhead. Parsing is faster, noticeably so once request volume climbs.

It has gaps. No comments inside the data, which bites hardest in configuration files. No built-in schema standard as mature as XSD, though JSON Schema has closed most of that distance. And it gets awkward the moment you try to represent markup sitting inside text.

Rough rule: data meant for a program to consume leans JSON. Data that also needs to read like a document, with markup woven into the text, leans XML.

How to Create an XML Document

Hand-coding it in a text editor or generating it from a script, the sequence is the same.

1. Write the XML declaration as the first line, <?xml version="1.0" encoding="UTF-8"?>
2. Add a single root element that will wrap everything else in the document
3. Nest child elements inside the root, using attributes for metadata and text content for values
4. Save the file with a .xml extension, then run it through a validator or parser to confirm it’s well-formed

Oxygen XML Editor and the XML extensions built into Visual Studio Code both validate a document against its schema as you type, catching a missing closing tag long before you try to run the file.

Small files are fine by hand. Past a few hundred records most teams generate XML programmatically instead, using a library that builds the tree and handles escaping, because manually escaping ampersands across a thousand records is exactly how mistakes get in.

Once a document exists, the next job is often moving the data somewhere else entirely, converting an XML file to CSV for a spreadsheet, for instance.

First-timers trip on the same few things. Forgetting the XML declaration, which most parsers tolerate but some validators flag. Leaving an attribute value unquoted. Ending up with two root elements without noticing.

When XML Does Not Apply

XML earns its keep when data has real structure worth describing. Nesting, mixed content, validation that has to hold. Plenty of data has none of that.

Twitter dropped XML, Atom, and RSS support entirely from its API in 2012, moving to JSON only and calling the older formats infrequently used by that point. That decision marks the line pretty well.

Mobile APIs are the obvious wrong fit, where every extra byte of payload costs bandwidth and battery on a metered connection. Flat data with no nesting, an inventory count or a single configuration value, doesn’t need the tag overhead either. High-frequency streams like real-time price feeds or sensor telemetry care about parsing speed far more than schema strictness. And a team with no schema discipline ends up with freeform XML and nothing behind it, no DTD, no XSD, which is just inconsistent text with extra brackets.

SOAP usage among API developers fell from 34% to 26% between 2022 and 2023, while GraphQL rose to 29% and overtook it, according to Postman’s State of the API Report.

New API work defaults to JSON and REST now unless something specific pulls it back. Existing infrastructure, a regulatory mandate, a legacy integration nobody is funding a rewrite for.

A decent test: if you could swap every XML tag for a JSON key and lose no meaning, XML was never the right call to begin with.

Origin and Governance of XML

The World Wide Web Consortium governs XML, the same body that maintains HTML, CSS, and most core web standards.

Work began in 1996, when the W3C formed a working group to cut SGML down into something practical for the web. Jon Bosak of Sun Microsystems chaired it. Tim Bray of Textuality and C. M. Sperberg-McQueen served as co-editors of the resulting specification, alongside Jean Paoli of Microsoft. James Clark was technical lead and wrote Expat, one of the first widely used XML parsers.

XML 1.0 became a W3C Recommendation on 10 February 1998. The founding working group had 11 members, drawn from companies including Sun, Microsoft, Netscape, and Hewlett-Packard. The W3C XML Core Working Group maintained the specification for years and closed in 2016 once XML had reached full stability; W3C staff handle any remaining errata directly now.

Bosak got formal recognition later. In 2000, the W3C XML Plenary reserved the identifier “xml:Father” for him in perpetuity.

FAQ on What Is Xml

What Does XML Stand For?

Extensible Markup Language. The first word is the one that matters, since you define your own tags and structure instead of working from a fixed set the way HTML does.

Is XML a Programming Language?

No. There are no loops, functions, or logic anywhere in it, only data and structure. A separate program, script, or parser reads the file and decides what to do with what it finds.

What Is the Difference Between a Well-Formed and a Valid XML Document?

Well-formed covers syntax: closed tags, proper nesting, one root element. Valid goes further and means the document also matches a specific schema, a DTD or XSD, defining which elements and data types are allowed.

What Tools Are Used to Write or Validate XML?

Altova XMLSpy has been the commercial editor of choice for XML and XSD work for a long time. On the command line, xmllint, part of the libxml2 project, checks a document’s syntax and validates it against a schema in one step, no GUI involved.

What Common Errors Break an XML Document?

Unclosed tags, mismatched nesting, and unquoted attribute values account for most of it. A second root element or an unescaped ampersand does the same damage just as fast, and the parser refuses the whole file either way.

Is XML Still Used Today?

Yes, just not as the default for new APIs. Banking messaging, office file formats, and podcast feeds all still run on it, as do plenty of enterprise systems built years ago around SOAP and XSD-based data contracts.

How Do You Open an XML File?

Any text editor opens it as plain text. Modern browsers open it directly too and render the tag tree in a collapsible view, which is usually enough to see what you’re dealing with. For editing or validation, a dedicated XML editor reads and checks the structure at once.

What Does XML Cost to Maintain Over Time?

Cost climbs the moment a document’s structure outgrows what a person can check by eye. That’s the point where a schema stops being optional and becomes the only thing standing between you and silent data corruption.

Lock a schema in early, DTD or XSD, before the tag set grows in whatever direction people feel like taking it. Match the parser to file size, DOM for small documents and SAX for large exports. And keep a migration path in mind for the day the data simplifies enough that XML stops earning its place.

The trade-off is upfront time. Locking a schema down early buys years of stable validation, but it costs design hours that small projects almost always skip.

That same structured data often ends up loaded into a page without a refresh, a pattern called Ajax, whose name was built around XML from the start.