XML: Structure, Validation and Common Errors

XML looks intimidating mostly because you usually meet it at its worst: a single unbroken line of forty thousand characters that some system rejected without explaining why. Underneath, the format is simple — a tree of nested elements — and almost every failure comes down to a handful of syntax mistakes. You can indent and check any document with the Docuboxer XML formatter, which runs entirely in your browser.

Formatting, ordering and validating are three different things

These three operations get lumped together, but they solve different problems:

• Formatting (indenting): adds line breaks and consistent indentation so the hierarchy is readable. It touches only the whitespace between tags, never the data.
• Ordering: what most people mean when they say they want to "sort" an XML that arrived on one line — indentation by depth already lays the node tree out, placing each element under its parent.
• Validating: checks the document obeys XML syntax rules. Without it, anything consuming the file (a SOAP API, an e-invoicing system, an RSS feed) will fail.

How an XML document is structured

Every XML file is a single tree. One root element wraps everything else; each element may hold text, attributes or further elements. That is essentially the whole model, and it is why XML maps so naturally onto documents like invoices, configuration files and catalogues, where things genuinely do nest inside other things.

An optional prolog — <?xml version="1.0" encoding="UTF-8"?> — declares the version and character encoding. That encoding declaration matters more than it looks: if it disagrees with how the file was actually saved, every accented character in the document turns to mojibake.

The most common XML syntax errors

XML is strict by design. One misplaced character invalidates the entire document, which feels harsh until you realise it is exactly what makes XML parsers interoperable. These are the failures validation catches most often:

• Unclosed tags: <customer> without its </customer>. The classic hand-editing mistake.
• Crossed nesting: <a><b></a></b>. HTML browsers forgive this; XML never does.
• Unescaped special characters: a literal & in text must be written &, and < as <. Extremely common with URLs that carry query parameters inside a node.
• Unquoted attributes: id=123 instead of id="123".
• More than one root element: valid XML has exactly one node wrapping all the others.
• Wrong encoding declaration: the prolog claims UTF-8 but the file was saved as something else, and the accents break.

A formatter with built-in validation reports the line and the reason, which turns a blind hunt through forty thousand characters into a ten-second fix.

Checking an XML file, step by step

1. Open the tool: go to XML formatter.
2. Paste the content: or drop the file straight into the editor.
3. Format: one click indents the document and runs syntax validation at the same time.
4. Fix and export: errors are reported with their location; correct them, then copy or download the clean XML.

All of it happens inside your browser — which matters more with XML than with almost any other format, because real-world XML tends to be sensitive: electronic invoices, server configuration with credentials in it, full database exports.

Where XSD validation fits in

Syntax validation asks whether the document is well-formed. Schema validation (XSD) additionally asks whether its structurehonours a contract: which elements exist, in what order, with which types. For the everyday question — "why won't this file open?" — syntax validation is what you need first, because an XML that isn't well-formed will fail against any schema anyway. If your workflow demands strict XSD validation, as e-invoicing usually does, clean up the syntax first and then validate against your provider's official schema.

XML and JSON: cousins that coexist

Work with APIs for long enough and you will live with both: XML in legacy systems, SOAP and invoicing; JSON in REST APIs. The hygiene rules are identical — format so you can read it, validate before you process it, and never paste sensitive data into a tool that uploads your content. For the JSON side there's the JSON formatter, and we cover the privacy problem with online formatters in this article.

Frequently asked questions

Related tools

• XML formatter — Indent and validate XML in your browser.
• JSON formatter — The same for the other big data format.
• YAML formatter — For configuration files.

You might also like: why privacy matters when you format data online and when to use CSV and when to use JSON.