What is an XML file, really — from someone who maintained one for six years

XML stands for eXtensible Markup Language, which is accurate and tells you almost nothing useful. The W3C specification is the authority, and it is not written for someone who just needs to get through the afternoon. Here is the version I give people joining a team that owns one.

It is a format for making text self-describing

Suppose you have to move this between two systems:

447700900142,Unlimited 5G,true,-92

Perfectly good CSV, and completely dependent on outside knowledge. What is the third column? Is -92 a signal reading or an account balance? The meaning lives in a spec document somewhere, or in someone's memory. When that person leaves, the file becomes a puzzle.

XML puts the meaning inside the file:

<subscriber msisdn="447700900142">
  <plan>Unlimited 5G</plan>
  <roaming>true</roaming>
  <rsrp unit="dBm">-92</rsrp>
</subscriber>

Longer, and now it explains itself. Someone opening this in ten years knows -92 is an RSRP reading in dBm without finding any documentation. That is the entire point of XML. Every design decision in it follows from that goal, including the verbosity people complain about.

The parts of an XML file

<?xml version="1.0" encoding="UTF-8"?>   <!-- declaration -->
<subscribers>                             <!-- root element -->
  <subscriber msisdn="447700900142">      <!-- element with an attribute -->
    <plan>Unlimited 5G</plan>             <!-- element with text content -->
    <rsrp unit="dBm">-92</rsrp>
    <notes/>                              <!-- empty, self-closing -->
  </subscriber>
</subscribers>

• Declaration — version and character encoding. Optional, but always include it, and nothing may come before it.
• Root element — exactly one outermost tag wrapping everything. Two roots is not a valid document.
• Elements — <tag>content</tag>. Must nest properly; they cannot cross over each other.
• Attributes — name="value" on the opening tag. Always quoted, no exceptions.
• Self-closing tags — <notes/> for an element that exists but holds nothing.

Attributes vs elements: the question everyone asks

Both of these are valid, and new joiners always want to know which is correct:

<!-- as an attribute -->
<subscriber msisdn="447700900142" plan="Unlimited 5G"/>

<!-- as elements -->
<subscriber>
  <msisdn>447700900142</msisdn>
  <plan>Unlimited 5G</plan>
</subscriber>

There is no official ruling, and arguments about it have consumed more engineering hours than they deserve. The rule of thumb that has served me:

There is also a practical constraint that settles many cases: attributes cannot repeat and cannot nest. One msisdn attribute per tag, and its value is always flat text. The moment a field might occur twice, or gain internal structure, it has to be an element. Choosing attributes for genuine data is the single most common cause of painful XML migrations later.

Namespaces, without the spec language

This is the concept that reliably stops juniors. The problem it solves is simple: two organisations both invent a <title> tag. Yours means a job title, theirs means a document heading. Now you must combine both in one file.

<record xmlns:hr="https://example.com/hr"
        xmlns:doc="https://example.com/docs">
  <hr:title>Network Engineer</hr:title>
  <doc:title>Q3 Capacity Review</doc:title>
</record>

The prefixes hr: and doc: keep them apart. This is defined by Namespaces in XML, a separate spec from XML itself. xmlns:hr="..." declares that within this document, hr: is shorthand for that URI.

What matters in practice is that the prefix is arbitrary — the URI is the real identity. These two documents are identical as far as any parser is concerned:

<hr:title xmlns:hr="https://example.com/hr">Network Engineer</hr:title>
<x:title  xmlns:x="https://example.com/hr">Network Engineer</x:title>

Which is why XPath that matches on the prefix instead of the namespace URI breaks the moment a partner regenerates their file with different prefixes. It is a genuinely common production bug.

Well-formed vs valid

These get used interchangeably and mean different things.

A document can be well-formed and still wrong for its purpose. This parses perfectly and is useless to a billing system expecting an MSISDN:

<subscriber>
  <favouriteColour>teal</favouriteColour>
</subscriber>

That is what an XSD is for — a separate file stating which elements must appear, in what order, how many times, and of what type. It is why XML persists in banking, insurance, healthcare and telecoms: "does this file meet the contract?" has a definitive, machine-checkable answer that does not depend on reading anyone's source code.

Where you will actually meet XML

• Office documents. A .docx is a ZIP of XML files. Rename one to .zip and look inside — it is a good way to see real-world XML.
• RSS and podcast feeds. Every podcast app on earth reads XML.
• Configuration — Maven pom.xml, Android layouts, .NET config, Spring.
• SVG. Vector graphics are XML, which is why you can edit them in a text editor.
• Enterprise integration — SOAP, ISO 20022 in payments, HL7 in healthcare, 3GPP interfaces in telecoms.
• Sitemaps. The file search engines read from your site is XML.

Worth a look: rename a .docx to .zip, unzip it, and open word/document.xml. It is the clearest demonstration of how much XML you already use. If you want the other side of the argument, JSON vs XML covers when each one is the right call. That list is the real answer to "is XML dead?". It is not dead, it stepped back from one job — shipping data to browsers — where JSON is simply better suited. Everywhere the requirement is a durable, self-describing, independently verifiable document, XML is still doing the work.

If you need it as something else

Most of the time someone hands you XML, you want it in a shape you can actually work with. Converting to JSON makes it easy to handle in code; converting to a table or CSV makes it easy to eyeball or hand to someone in a spreadsheet.

The short version

• XML is plain text that carries its own description of what it means.
• One root element; everything nests properly inside it.
• Attributes describe values; elements hold data. Attributes cannot repeat or nest.
• Namespaces stop tag names colliding. The URI is an identifier, not a link.
• Well-formed = legal syntax. Valid = matches an agreed schema. Not the same thing.

If you just need to get a file open first, see how to open an XML file.