The first time XML nearly ruined my afternoon, it was a SOAP response from a payment gateway. One line. Eleven thousand characters. No newlines, no indentation, just an unbroken wall of angle brackets that my terminal wrapped into an unreadable brick. Somewhere in there was a single wrong element causing a signature mismatch, and I was supposed to find it by eye. I have built plenty of things since then - WordPress plugins, Laravel APIs, the React tooling behind toolz.dev - and I can tell you that a good XML formatter is one of those quiet utilities you do not appreciate until the moment you are staring at a wall of tags with a deadline behind you.
This guide is the one I wish I had that afternoon. It covers what an XML formatter actually does, why beautifying and minifying are two sides of the same coin, the whitespace rule that makes formatting safe, and the handful of validation errors that account for nearly every "why won't this parse" moment. You can follow along in the browser with the free XML Formatter - it runs entirely on your machine, so even a payment payload never leaves your laptop.
TL;DR: An XML formatter re-writes a document's insignificant whitespace - the space between tags - without touching its meaning. Beautify adds line breaks and indentation so you can read the hierarchy; minify strips all of it so the file is as small as possible. A good formatter preserves comments, CDATA, the XML declaration, and attribute order, and validates well-formedness (matching tags, closed elements, terminated sections) along the way. It does not check your document against a DTD or XSD schema - that is a different job.
What does an XML formatter actually do?
Whitespace is where formatting gets interesting, because XML 1.0 requires a parser to pass every character inside an element through to the application - which is why a formatter has to know what it is safe to touch. At its core, an XML formatter parses your document into a tree of nodes - elements, text, comments, CDATA sections, processing instructions - and then serializes that tree back out with consistent spacing. That round trip is the whole trick. Because the tool understands the structure rather than doing a blind find-and-replace, it can indent a deeply nested <order><items><item> chain correctly, put each sibling on its own line, and know that the text inside <price>44.95</price> should stay on the same line as its tags rather than sprawling across three.
The reason this matters comes down to a rule buried in the XML specification: most of the whitespace between elements is insignificant. When a parser reads <a>\n <b/>\n</a>, the newlines and spaces around <b/> are there for humans and carry no data. A formatter is allowed to add, remove, or change that whitespace freely. What it must never touch is significant whitespace - the characters inside a text node like <note>Call me at 9am</note>, or anything inside a CDATA block - because that content is real data. Every formatting decision the XML Formatter makes flows from respecting that line.
So beautifying is not cosmetic fluff. When you re-indent that eleven-thousand-character SOAP brick, the element hierarchy becomes visible, and suddenly the misplaced <Amount> node three levels too deep is obvious. Formatting is a debugging tool as much as a readability one.
Why would I minify XML instead of beautifying it?
Beautify and minify are the same engine pointed in opposite directions. Beautify adds whitespace for humans; minify removes it for machines. You reach for minify when size or transport matters: shrinking a configuration file that ships inside a mobile app bundle, trimming a request body before it goes over a slow connection, or normalising a document so two versions can be compared byte-for-byte without indentation noise getting in the way.
The saving is real but rarely dramatic. XML's verbosity lives in its repeated tag names, not its whitespace, so minifying typically trims somewhere between five and twenty percent depending on how heavily indented the original was. That is worth having, but if you need serious compression, gzip on the wire does far more - minifying and then gzipping is the belt-and-braces approach many APIs use.
Here is the mental model I use when deciding which way to point the tool:
| Situation | Beautify | Minify |
|---|---|---|
| Reading or debugging a response by eye | Yes | No |
| Committing a config file to version control | Yes (clean diffs) | No |
| Shipping XML inside an app bundle or over the network | No | Yes |
| Storing many small documents in a database column | No | Yes |
| Preparing a document for a byte-for-byte diff | Either, consistently | Either, consistently |
| Handing XML to another developer | Yes | No |
The key discipline is consistency. If you are diffing two documents, run both through the same mode with the same options first - otherwise you are comparing indentation styles, not content.
How does formatting avoid changing my data?
This is the anxiety every formatter has to earn its way past: "if this tool rewrites my XML, how do I know it did not quietly break something?" The honest answer is that a well-built formatter only ever changes the whitespace between tags, and leaves four things strictly alone.
The first is text content. The characters inside an element are copied verbatim. That includes entities - a literal & stays &, it is never helpfully decoded to & (which would produce invalid XML) or double-encoded to &amp;. The XML Formatter treats your text as opaque, which is exactly what you want.
The second is CDATA sections. A <![CDATA[ ... ]]> block exists precisely so you can drop raw, unescaped content - a snippet of JavaScript, a chunk of HTML, a string full of < and & - into an XML document without escaping it. A formatter emits that content exactly as it found it, no escaping, no re-indenting inside the block.
The third is comments and the declaration. Comments (<!-- ... -->), the <?xml version="1.0"?> declaration, and any processing instructions are preserved and placed sensibly. You can choose to strip comments when you want a leaner file, but that is your decision, not something the tool does behind your back.
The fourth is attribute order and quoting. By default the formatter keeps your attributes in the order you wrote them, with the quote style you used, because the XML specification treats attribute order as insignificant and there is no reason to churn it. When you do want a canonical ordering - for cleaner diffs, or to compare two elements that carry the same attributes in different orders - a "sort attributes" option puts them in alphabetical order for you.
Because all of this runs client-side in JavaScript, there is a privacy dividend too: a document full of connection strings, internal identifiers, or customer records is formatted on your own machine and never uploaded. If you care about keeping working data off other people's servers - and you should - that model is worth understanding, and I wrote more about it in the data privacy guide for online tools.
What XML errors does the formatter catch?
Before a formatter can pretty-print anything, it has to parse the document, and parsing is where the useful validation happens. This is well-formedness checking - the structural rules every XML document must obey - and in my experience three mistakes account for the overwhelming majority of failures.
The most common by far is a bare ampersand. XML reserves & to start an entity, so a raw & in text - the kind that sneaks in through a URL like ?a=1&b=2 or a company name like "Marks & Spencer" - makes the parser expect an entity name and then choke when it does not find one. The fix is to write &, and a good error message will point you at the line so you are not hunting blind.
The second is a mismatched or unclosed tag. Open a <div> and close it with </section>, or open a <span> and never close it at all, and the document is no longer well-formed. The formatter tracks the open-element stack as it parses, so it can tell you exactly which tag it expected to see closed and which one it actually found. That single message - "expected </book> but found </author> at line 14" - is usually enough to solve the problem in seconds.
The third is an unterminated section: a comment opened with <!-- that never reaches -->, or a CDATA block that never reaches ]]>. These are easy to create when you are hand-editing and delete a little too much. Again, the formatter reports the line where the runaway section began.
What the formatter does not do is check your document against a schema. Well-formedness asks "is this structurally valid XML?" Validity asks "does this XML follow the rules of my particular document type - the right elements, in the right order, with the right data types - as defined by a DTD or XSD?" Those are separate layers. A document can be perfectly well-formed and still be nonsense for its intended purpose. Schema validation needs the schema, and that is a different tool. The formatter guarantees the first layer, which is the one that stops your parser crashing.
How do I format XML in my editor or build pipeline?
The browser tool is the fastest path for a one-off document, but it is worth knowing the alternatives so you can pick the right one for the job.
Most editors format XML natively. In VS Code, the built-in "Format Document" command (Shift+Alt+F) handles XML, and extensions like Red Hat's XML language server add schema-aware formatting on top. IntelliJ and its siblings reformat with Ctrl+Alt+L. These are ideal when the file is already open in front of you.
On the command line, xmllint --format file.xml (part of libxml2, which ships on most Unix systems) beautifies, and xmllint --noblanks file.xml gets you close to minified output. In a Node project, libraries like xml-formatter or prettier with the XML plugin slot into a build step. Python developers reach for xml.dom.minidom.parseString(s).toprettyxml(), though be warned it is notorious for adding extra blank lines around existing whitespace.
So why use the XML Formatter at all? Three reasons I keep coming back to. It needs no installation, no configuration, and no project - you paste and go. It keeps the data on your machine, which matters when the XML is a real payload rather than a toy example. And it pairs naturally with the neighbouring tools: once your XML is clean and valid, converting it to JSON with the XML to JSON converter is one click, and the reverse trip through JSON to XML uses the same conventions. If your day is mostly JSON, the JSON Formatter is the equivalent for that format, and the whole family is catalogued in the web developer toolkit.
When should I format versus convert my XML?
A question I get from people newer to this: if JSON is easier to read, why format XML instead of just converting it? The answer is that formatting and converting solve different problems.
Format when you need to keep the XML - because a SOAP endpoint demands it, because an RSS or Atom feed is XML by definition, because your config file, your Android layout, or your Maven pom.xml simply is XML and always will be. Formatting makes that XML readable or compact while leaving it as XML. Nothing downstream has to change.
Convert when you want to work with the data in a different format - pulling values into a JavaScript front end, loading a feed into a system that speaks JSON, or normalising several sources into one shape. Conversion changes the format, and with it some of the fidelity: XML attributes, mixed content, and element ordering do not have clean JSON equivalents, so a converter makes deliberate choices (attributes become prefixed keys, repeated tags become arrays) that you should understand before you rely on them.
My rule of thumb: format first, always. A clean, validated document is easier to reason about whether your next step is editing it, diffing it, or converting it. Formatting is the cheap, safe, lossless operation; conversion is the lossy one you do once you know the structure is sound. Sitemaps are a nice example of XML you format rather than convert - if you are building one, the dedicated sitemap generator produces valid, well-formed output directly.
Frequently asked questions
How do I format XML online?
Paste your XML into the input panel, choose Beautify, pick an indentation width, and click Format. The tool parses the document, re-indents it, and lets you copy or download the result. All processing happens in your browser - nothing is uploaded.
What is the difference between beautifying and minifying XML?
Beautifying adds line breaks and indentation so the element hierarchy is easy to read, which is ideal for editing and debugging. Minifying removes all the whitespace between tags to produce the smallest possible file, which is ideal for storage or sending over the network. Both preserve the document's meaning; only the insignificant whitespace changes.
Does formatting change the meaning of my XML?
No. Only the whitespace between tags is altered - the elements, attributes, text content, comments, and CDATA are unchanged. Because significant whitespace inside text nodes and CDATA is preserved, a well-formed document behaves identically before and after formatting.
Are comments and CDATA sections preserved?
Yes. Comments, CDATA sections, the XML declaration, and processing instructions are all kept. Comments are indented alongside the elements they sit with, and CDATA content is emitted verbatim without any escaping. You can also choose to strip comments if you want a leaner output.
Can this tool validate my XML?
Yes. Before formatting, the document is fully parsed, and structural problems - an unclosed element, a closing tag that does not match its opening tag, or an unterminated comment or CDATA section - are reported with a line number so you can fix them quickly. It checks well-formedness, not validity against a DTD or XSD schema.
Why is my XML failing to format?
Almost all failures are well-formedness errors. The most common are a bare ampersand in text (it must be written as an entity, or the parser reads it as the start of an entity), a closing tag that does not match the element it closes, and an element that is opened but never closed. The error message points at the line so you can jump straight to it.
Is it safe to format XML that contains sensitive data?
Yes. The parser runs entirely in JavaScript in your browser - no network request carries your data, nothing is logged or stored, and the tool works offline once loaded. XML holding API keys, connection strings, or customer records never leaves your machine.
Can I convert the formatted XML to JSON afterward?
Yes. Once the XML is clean and valid, the XML to JSON converter turns it into equivalent JSON, mapping attributes to prefixed keys and repeated tags to arrays. Formatting first makes the structure obvious, which helps you understand how it will map before you convert.
Written by Liton - builder of toolz.dev, WP Adminify, and a long list of Laravel and React projects. Every tool mentioned here runs free and fully in your browser at toolz.dev.
