ABC Tools

XML Formatter and Validator, Explained

After reading this you will know what "well-formed XML" actually means at the byte level, how pretty-printing and minifying change the bytes without changing the data, and how to read a validation error and jump to the exact line that broke.

What this tool does, with one example

XML is a text format for tree-shaped data. Every piece of content sits inside a tag, tags nest inside other tags, and exactly one tag wraps the whole thing. This formatter takes raw XML text and does three jobs: it re-indents it so the tree structure is visible, or collapses it to one line, and it checks that the document is well-formed before doing either.

Here is a small document as one unreadable line:

<note><to>Ada</to><from>Grace</from><body>Hi</body></note>

Pretty-printed with two-space indentation it becomes five lines:

<note>
  <to>Ada</to>
  <from>Grace</from>
  <body>Hi</body>
</note>

The characters between the tags did not change. The tool only added newline and space characters (bytes 0x0A and 0x20) between elements. The data payload is identical.

Well-formed versus valid

These two words get mixed up constantly. They mean different things.

Well-formed
The document follows the syntax rules of XML: every opening tag has a matching closing tag, tags nest without crossing, attribute values are quoted, and there is exactly one root element. This is a purely structural check.
Valid
The document also matches a specific schema (a DTD, XSD, or RELAX NG) that says which elements are allowed, in what order, and with what attributes. This is a semantic check against a named contract.

This tool checks well-formedness only. It will accept <note><color>banana</color></note> because the tags match, even if no schema in the world expects a color inside a note. Well-formedness is the floor. A parser cannot even build a tree without it, so it is the first thing to get right.

The three rules that catch most errors: one root element, every tag closed, and no crossed nesting. <b><i>x</b></i> crosses because <i> opens inside <b> but closes outside it. Correct is <b><i>x</i></b>.

When to format, when to minify

Reach for pretty-printing when a human needs to read or diff the file. Indentation makes the nesting depth obvious at a glance, and it puts each element on its own line so a line-based diff tool shows one changed element per changed line instead of one changed blob.

Reach for minifying when a machine consumes the file and size or transfer time matters. Removing indentation from the five-line example above saves 14 bytes (four newlines plus ten spaces), which is about a 15 percent reduction on a 92-byte document. On a large configuration file with thousands of nested elements, stripping whitespace routinely cuts 20 to 40 percent.

Do not minify a file whose whitespace is significant. In some documents the text between tags carries meaning (a poem, preformatted text, or an element whose xml:space="preserve" attribute is set). Collapsing that whitespace changes the data. The safe rule: format for editing, keep the original for shipping, and only minify data-oriented XML where element text has no meaningful leading or trailing spaces.

How pretty-printing decides indentation

Indentation is a function of depth. The root sits at depth 0, its children at depth 1, their children at depth 2, and so on. With an indent unit of n spaces, an element at depth d gets n \times d leading spaces.

\text{leading spaces} = n \times d

Here n is the chosen indent width (commonly 2 or 4) and d is how many ancestors the element has. In the note example, <to> has one ancestor (<note>), so d = 1, and with n = 2 it gets 2 \times 1 = 2 leading spaces. The root <note> has d = 0 and gets 2 \times 0 = 0 spaces.

The total bytes added by pretty-printing is the sum over every element of its own leading spaces plus one newline. A document with many deeply nested elements grows faster than a flat one, because each extra level of depth multiplies the space count for everything inside it.

With 2-space indentation, an element at depth 3 gets 6 leading spaces; at 4-space indentation it gets 12. Doubling the indent width doubles the leading whitespace at every depth, so deeply nested files grow fastest.

Worked example: the demo document

Formatting the note document step by step

Start from the minified input and trace what a pretty-printer does.

  1. Parse the text into a tree. The parser reads <note> and pushes it as the root at depth 0.
  2. It reads <to>, pushes it at depth 1, reads the text Ada, then reads </to> and pops back to depth 1's parent.
  3. Same for <from>Grace</from> and <body>Hi</body>, each at depth 1.
  4. It reads </note> and pops the root. The stack is now empty, which confirms every tag was closed.
  5. Now it writes the tree back out. Root at 0 spaces, its three children at 2 \times 1 = 2 spaces each, each on its own line.

Count the added bytes: four newlines plus 3 \times 2 = 6 leading spaces on the three children, so 10 bytes total. The minified form was 62 bytes; the pretty form is 72 bytes.

Each depth-1 child gets 2 leading spaces; the root gets none. The four newlines are counted separately.

Reading validation output

When a document is not well-formed, the parser stops at the first byte it cannot make sense of and reports a position. The tool turns that into a line hint. Treat the reported line as the place the parser gave up, which is not always the place you made the mistake.

The classic example is a missing closing tag. If you forget </from>, the parser does not notice until it reaches </note> and finds a from still open on its stack. The error points at the </note> line, several lines below the real problem. When the reported line looks innocent, scan upward for an element that never closed.

Read the error message from the parser's point of view. "Expected end tag </from> but found </note>" tells you the open element it still had on the stack. That name, not the line number, is your best clue.

The stats panel reports element count, maximum nesting depth, and attribute count. A maximum depth that is much larger than you expected often means a tag never closed and everything after it counts as nested inside. A sudden jump in element count between two edits can flag a duplicated block you pasted twice.

Common mistakes

Five errors account for most failed validations.

  • Two root elements. <a/><b/> at the top level is not well-formed. Wrap both in a single parent.
  • Unescaped special characters. A literal < or & in text breaks the parser. Write &lt; and &amp;. A stray & in a URL query string is the most common offender.
  • Unquoted attribute values. <p count=3> is rejected. XML requires count="3" with quotes.
  • Mismatched case. XML is case sensitive. <Note>...</note> does not match.
  • A byte order mark or stray characters before the declaration. Anything before <?xml ...?>, including an invisible BOM (0xEF 0xBB 0xBF), makes the declaration illegal. If a file fails on line 1 for no visible reason, suspect a BOM.

Comments (<!-- ... -->) and CDATA sections are preserved exactly, so you can keep documentation and raw text blocks through a format or minify pass without them being reindented or escaped.

Related tools

XML is one of several structured text formats you may be moving between. The vCard Generator and Parser and the iCalendar Generator and Parser handle two line-based contact and calendar formats that people often need alongside XML feeds. If your XML is really a data table in disguise, the Chart Maker can turn extracted values into a bar or line chart. Working with JSON instead? The JSON to Types Generator produces typed models from a sample. And when you need sample records to test an XML pipeline, the Test Data Generator produces CSV or JSON datasets you can convert.

Frequently asked questions

Does formatting change my data?

No. Pretty-printing only inserts newlines and spaces between elements, and minifying removes them. The text content and attribute values inside tags are untouched. The one caveat is whitespace that carries meaning, such as elements marked xml:space="preserve", which you should not minify.

Why does it say line 20 when my mistake is on line 12?

The parser reports where it could no longer continue, not where you went wrong. A tag left open on line 12 is only detected when a mismatched closing tag appears later. Read the message for the expected tag name and search upward for the element that never closed.

Will it validate against my XSD or DTD?

No. It checks well-formedness only: matching tags, proper nesting, and a single root. It does not confirm that your document obeys a specific schema. For that you need a schema-aware validator with your XSD or DTD loaded.

Is my file uploaded anywhere?

No. The tool runs entirely in your browser. The XML you paste or open never leaves your device, which matters when the document contains names, addresses, or other personal data.

What indentation should I choose?

Two spaces is the common default and keeps deep files narrow. Four spaces is easier to scan at shallow depth. Tabs work too. The choice is cosmetic and does not affect whether the document is well-formed, so pick what your team's diffs read best in.

Try it yourself in the tool

Related tools

JSON → Types Generator

Generate TypeScript, Python or Go types from JSON.

Test Data Generator

Fake names, emails, addresses — CSV or JSON datasets.

iCalendar Generator & Parser

Create .ics event files and inspect existing ones.

vCard Generator & Parser

Create .vcf contact files and inspect existing ones.

Auto Analyst: Instant Statistical Report

Drop a CSV or Excel file and get a statistician’s report: data problems, distributions, every real relationship, key drivers and Simpson’s paradox warnings, in plain English.

CSV Viewer & Editor

View, edit, sort, filter and extract columns from CSV files.