What Is XML and When Should You Still Use It

October 17, 2026 • NOFYI Editorial Team

XML stands for Extensible Markup Language. It is a way to store and share structured data using tags that you define. If you have ever looked at an RSS feed, a sitemap, a configuration file, or an export from an older system, you have probably seen XML. It looks a little like HTML, because both use angle brackets and tags, but their purposes are different. HTML describes how content should be presented. XML describes what data means.

Many people assume XML is outdated because JSON has become more common for web APIs. JSON is often simpler and lighter, and for many new projects it is the better choice. Yet XML is still used in publishing, document formats, enterprise systems, feeds, and integrations where its strict structure, validation, and long history matter. Understanding XML helps you work with those systems, even if you do not choose XML for a new project.

This guide explains what XML is in plain language, how tags and attributes work, and how to read a simple document. You will see a worked example of a book catalog, compare JSON and XML, and learn when XML is still a good fit. You will also learn when not to use XML, especially for simple configuration where a simpler format would be clearer.

What XML Is

XML is a text format for structured data. A document is built from elements, which are marked by start and end tags. Each element can contain text, other elements, or both. Attributes add extra information to an element, such as an identifier or a category. The result is a tree: one root element contains everything else, and each level nests inside the level above it. That tree structure makes XML easy to parse with software, because a program can walk from the root down through each branch.

XML is extensible because you are not limited to a fixed set of tags. You can create tags that match your data, such as book, title, author, and price. This freedom is useful, but it also means two systems must agree on the tag names and structure before they can exchange data reliably. That agreement is often recorded in a schema, which describes which elements are allowed, which ones are required, and what kind of values they can hold.

XML is also strict. Tags must be properly nested, closing tags must match opening tags, and attribute values must be quoted. Special characters such as less-than and ampersand must be escaped or placed in a special section. This strictness can feel annoying when you are writing by hand, but it helps software catch mistakes early. A malformed XML document is not guessed at; it is rejected, which makes errors easier to find.

How Tags and Attributes Work

An element starts with an opening tag, such as book, and ends with a matching closing tag. The text or child elements between those tags belong to that element. If an element has no content, it can be written as an empty element with a closing slash. Indentation does not change the meaning of the data, but it helps a human reader see the nesting, just as indentation helps in HTML or code.

Attributes live inside the opening tag and provide metadata about the element. For example, a book element might have an id attribute, or a language attribute. A common guideline is to use child elements for data that is part of the content, and attributes for identifiers, labels, or settings that describe the element. That guideline is not a strict rule, but following it keeps documents consistent and easier to read.

Comments in XML use a distinctive syntax that is easy to recognize, and processing instructions can give hints to software that reads the file. Namespaces help when two vocabularies use the same tag name for different things, by qualifying a tag with a prefix that points to a specific definition. You do not need namespaces for a small, private file, but they become important when documents combine data from different sources.

How to Read and Write XML Step by Step

Start by identifying the root element. Everything else should sit inside it. Next, read the document as a tree: each child element is a piece of the parent, and siblings at the same level are peers. If a price sits inside a book, it describes that book. If a list of books sits inside a catalog, the catalog is the collection that holds them.

When you write XML, choose clear tag names that describe the data, not the layout. Use lowercase names with a consistent style, such as book-title or bookTitle, and do not mix styles in the same document. Keep the nesting shallow when you can. Deep nesting makes a document harder to read and harder to query. If you find yourself nesting many levels just to express a simple idea, the structure may need simplifying.

Validate your work when it matters. A validator can check that the document is well-formed, which means the tags are balanced and the syntax is correct. A schema check can go further and confirm that the structure matches what the receiving system expects. Validation does not prove the data is true, but it proves the data is in the agreed shape. For data that will be exchanged with another system, that check is worth doing before you send it.

Worked Example: A Book Catalog

Imagine a small book catalog with two books. Each book has a title, an author, a year, and a price. The catalog is the root element, and each book is a child of the catalog. The book id is stored as an attribute, because it identifies the book rather than forming part of its readable content. This example is deliberately small so the structure is easy to follow.

<catalog>
  <book id="b1">
    <title>The Quiet Library</title>
    <author>Maya Chen</author>
    <year>2021</year>
    <price currency="USD">14.99</price>
  </book>
  <book id="b2">
    <title>Notes on Clear Writing</title>
    <author>Daniel Okafor</author>
    <year>2023</year>
    <price currency="USD">19.50</price>
  </book>
</catalog>

To build a document like this, follow a short routine. First, name the root and decide what it contains. Second, list the fields for each item and decide which ones are elements and which ones are attributes. Third, write one item completely, then copy its structure for the next item so the two items match. Fourth, indent each level consistently and check that every opening tag has a matching closing tag. Fifth, read the document as data: can you find the title of the second book without guessing? If yes, the structure is working.

The same routine scales to larger catalogs, product feeds, and document exports. The key is consistency. If one book uses a price element and another uses a cost element, software that reads the catalog must handle both, which adds work and risk. A shared vocabulary, even a simple one written down in a short guide, prevents that problem.

JSON vs XML

JSON and XML can both represent structured data, and for many web applications JSON is simpler. JSON uses objects, arrays, strings, numbers, and booleans, and it maps naturally to the data structures in most programming languages. A JSON version of the book catalog would be shorter, with less markup around each value. That brevity makes JSON attractive for APIs, mobile apps, and browser code.

XML has strengths that JSON does not. XML supports comments, mixed content where text and tags are interleaved, and a mature set of tools for validation, transformation, and querying. Document formats, such as those used by word processors and publishing systems, often need mixed content, because a paragraph can contain bold text, a link, and a footnote in the middle of a sentence. XML handles that pattern naturally. XML also has a long history in enterprise and government systems, where schemas and contracts are important.

The practical rule is to use the format your audience and tools expect. If you are building a new web API for browsers and mobile apps, JSON is usually the simpler choice. If you are working with a document format, a feed, a sitemap, or an existing system that expects XML, use XML. If you are exchanging data between two systems, choose the format both sides can validate and test, rather than the one that looks shortest in an example.

When Should You Still Use XML

You should still use XML when the receiving system requires it, when you need strict validation, or when the data is document-like. Examples include RSS and Atom feeds, sitemaps for search engines, SVG graphics, office document formats, and configuration or data exchange in older enterprise systems. In those cases, XML is not a legacy quirk. It is the agreed language for that ecosystem, and using it correctly makes integration possible.

XML is also useful when you need to transform data from one shape to another. Stylesheet languages for XML can convert a document into HTML, another XML shape, or plain text. That transformation step is powerful for publishing, where the same source document may need to become a web page, a print file, and a feed. If your project needs that kind of transformation, XML may be worth its extra verbosity.

Another reason to keep XML is stability. Some formats and standards have been in use for decades, and changing them would break many tools. When you work with those standards, your job is not to redesign the format. Your job is to produce valid, clear documents that follow the standard, and to test them with the tools that will consume them.

Do Not Use XML for Simple Configuration

For simple configuration, XML is often more complex than needed. A small settings file with a handful of values does not need nested tags, closing tags, and escaping rules. A simpler format, such as JSON, YAML, TOML, or a basic key-value file, can be easier to read, easier to edit, and less error-prone. The simpler format also makes mistakes more visible, because there is less markup to hide them.

Consider a settings file that stores a site title, a language, and a port number. In XML, each value needs an opening and closing tag. In a simpler format, each value can sit on one line with a clear key and value. The simpler version is easier for a newcomer to edit, easier to review in a change, and easier to validate with a quick check. When the configuration grows complex, with repeated sections and strict rules, XML may become reasonable again, but that is the exception, not the default.

The same idea applies to small data exchanges. If two parts of your own application need to share a short list, a simple format is usually enough. Reserve XML for cases where its validation, document structure, or ecosystem support actually helps. Choosing the simplest format that meets the need is a form of good design.

Limitations

XML is verbose. Tags repeat for every value, which makes files larger and harder to scan than JSON for the same data. XML is also stricter to write by hand, because a single missing closing tag or an unescaped special character can make the whole document invalid. Those costs are acceptable when validation and document structure matter, but they are a burden for simple data.

XML does not guarantee meaning on its own. Two documents can both be valid XML and use different tag names for the same idea, which means software cannot understand them without a shared agreement. XML also does not handle every data type natively. Numbers, dates, and booleans are stored as text, and the receiving system must interpret them according to the schema or agreement. If that interpretation is not documented, errors can appear.

Finally, XML tooling varies. Some parsers are strict, some are forgiving, and some have security settings that matter when reading untrusted input. When you accept XML from an external source, use a parser with safe settings and follow the guidance for your language and library. Do not assume that because a file looks like XML, it is safe to process without checks.

Frequently Asked Questions

Is XML the same as HTML?

No. HTML has a fixed set of tags that describe presentation and structure for web pages, while XML lets you define your own tags to describe data. They share a similar syntax, with opening and closing tags, but they serve different purposes. A browser renders HTML. A parser reads XML as structured data, and the meaning of the tags depends on the agreement between the producer and the consumer.

When should I choose XML over JSON?

Choose XML when the system you work with requires it, when you need strict validation with a schema, or when the data is document-like with mixed text and markup. Choose JSON when you are building a typical web API, working with browser code, or exchanging simple structured data where brevity and easy mapping to programming objects matter more than document features.

What makes an XML document well-formed?

A well-formed XML document has one root element, properly nested tags, matching opening and closing tags, quoted attribute values, and correctly escaped special characters. Well-formed is the minimum requirement for a parser to read the file. A valid document goes further and also matches a schema, if one is used.

Should I use XML for a simple config file?

Usually no. For simple configuration, a simpler format is easier to read, edit, and review. XML adds markup for every value, which makes small files harder to scan and easier to break with a missing closing tag. Use XML for configuration only when the system requires it or when the configuration is complex enough that validation and structure provide a clear benefit.

Conclusion

XML is a strict, extensible format for structured data. Its tags and attributes form a tree that software can parse, validate, and transform. It remains useful for feeds, sitemaps, document formats, and systems that expect it, even though JSON is simpler for many new web APIs. Use XML when its validation, document features, or ecosystem support matter, and choose a simpler format for simple configuration. When you do use XML, keep tag names clear, keep nesting shallow, validate the result, and test it with the system that will read it.