Format XML
Formatting changes only the whitespace between tags. Text, attribute values, and CDATA sections come back exactly as they were. An element marked xml:space="preserve" keeps its original line breaks and spaces, while the rest of the document is re-indented around it. After every format, the page re-parses its own output and compares it with the input; if anything but whitespace changed, it shows the original instead, with a warning.
What an XML formatter does
An XML formatter reads a document into a tree of elements, then writes the tree back with line breaks and indentation between the tags. It never touches the content: the text inside an element, the values of its attributes, and the CDATA sections stay byte for byte the same. Only the whitespace that sits between tags changes.
That is why formatting is safe to run on a file you care about. A sitemap with 10,000 URLs reads the same to Google after formatting, and a SOAP envelope still carries the same request. The change is for human eyes only.
What formatting never changes
- Text inside elements, including spaces at the start and end of a line.
- Attribute values, in their original order.
- CDATA sections, comments (unless you ask to remove them), and processing instructions.
- Elements marked
xml:space="preserve", which keep their exact whitespace.
What it does change
- One element per line, indented one level under its parent.
- Elements that hold only text stay on one line, so
<title>Hello</title>does not split across three lines. - Empty elements keep the form you wrote:
<br/>stays self-closing,<br></br>stays open and closed.
Format vs minify
Beautify and minify are the same operation in opposite directions. One adds whitespace for reading, the other removes it for transport. Both keep the document well-formed and the content identical.
| Mode | What it does | Use it when |
|---|---|---|
| Format | Adds a line break and one indent level per element | Reading a config, debugging an API response, reviewing a sitemap |
| Minify | Removes all whitespace between tags, keeps text as-is | Shrinking a payload before sending it, storing XML in a database column |
| Validate | Changes nothing, reports well-formed or the first error with line and column | Checking a file before it goes into CI, a feed reader, or a parser |
| Convert to JSON | Maps elements to objects, attributes to @name keys, repeated children to arrays | Feeding XML data to a tool that only reads JSON |
A formatted file is bigger than the minified original: indentation adds one line break and a few spaces per element. A deeply nested document grows more than a flat one. Minify mode removes that whitespace again, so the two directions round-trip in size.
Errors the validator catches
The validator checks well-formedness, the same bar every XML parser applies. It reports the first error it finds, with the line and column where the problem starts. Fix that one and validate again; a document often has more than one error, and the parser stops at the first.
| Error | What it means | Typical cause |
|---|---|---|
| Mismatched close tag | </item> closes <entry> | A tag closed in the wrong order, or a typo in the closing name |
| Unclosed tag | A tag opened on line 4 was never closed | A missing close tag, often after a copy and paste |
| Multiple root elements | A second root starts after the first one closed | Two documents pasted into one file |
| Unescaped & | A bare & that starts no entity | Writing Tom & Jerry instead of Tom & Jerry |
| Unquoted attribute | An attribute value with no quotes | id=42 instead of id="42" |
| Text outside the root | Characters before the first tag or after the last close | A stray line pasted above the document |
The validator does not check your document against a schema or DTD. Whether an element is allowed in a given position depends on your schema, and that check belongs in your editor or CI pipeline, not in a formatter. The sample menu has a broken document ready to load, so you can see what an error report looks like before you paste your own file.
XML to JSON, and what gets lost
JSON has no attributes, no comments, and no mixed content, so a conversion has to make choices. This page uses one fixed mapping, and it says what it drops instead of guessing silently.
| XML part | JSON form |
|---|---|
| Element with only text | A string: <title>Hello</title> becomes "title": "Hello" |
| Attribute | A key with an @ prefix: <link href="/x"/> becomes "link": {"@href": "/x"} |
| Repeated child elements | An array, in document order |
| Text mixed with child elements | A #text key next to the child keys |
| Comments and processing instructions | Dropped, and the result says how many were dropped |
| CDATA section | Plain text, same as an ordinary text node |
Numbers stay strings in the conversion. XML has no number type, so <price>12.50</price> becomes "price": "12.50", not 12.5. Turning it into a number would drop the trailing zero and change the meaning. Convert types in your own code, where you know which fields are numbers.
Format XML in code
Use a maintained tool in production. The snippets below show the shape of the work, so the format is easy to check by hand.
xmllint, from libxml2
xmllint --format input.xml > formatted.xml
xmllint --format --noblanks input.xml > formatted.xml--noblanks drops the blank text nodes between tags before formatting, which is what you want for a document that was already formatted with different indentation. Without it, xmllint keeps the old whitespace and adds its own.
Python, standard library only
import xml.dom.minidom
tree = xml.dom.minidom.parse("input.xml")
print(tree.toprettyxml(indent=" "))Python's toprettyxml adds blank lines around text nodes, so the output usually needs a cleanup pass. For real work, lxml's etree.tostring(tree, pretty_print=True) behaves better.
PowerShell, built in
$xml = [xml](Get-Content input.xml)
$writer = New-Object System.Xml.XmlTextWriter("formatted.xml", $null)
$writer.Formatting = [System.Xml.Formatting]::Indented
$writer.Indentation = 2
$xml.Save($writer)
$writer.Close()Frequently asked questions
Is formatting XML safe? Will it change my data?
Formatting changes only the whitespace between tags. Text, attribute values, and CDATA sections come back exactly as they were, and comments stay unless you ask to remove them. This page re-parses its own output and compares it with the input; if anything but whitespace changed, it shows the original instead, with a warning.
Does this formatter validate against a schema or DTD?
No. It checks well-formedness only: tags opened and closed in the right order, one root element, quoted attribute values, and no stray characters. Whether an element is allowed in a given position depends on your schema, and that check belongs in your editor or CI pipeline, not in a formatter.
What does xml:space="preserve" do?
It tells the formatter that the whitespace inside that element is part of the content, not layout. A pre block, a code sample, or a poem keeps its exact line breaks and spaces, while the rest of the document is re-indented around it. The attribute is part of the XML 1.0 specification.
Why is the formatted file bigger than the minified one?
Indentation adds one line break and a few spaces per element. A deeply nested document grows more than a flat one, because each level adds its own indent. Minify mode removes that whitespace again, so the two directions round-trip in size.
Can I format a sitemap or an RSS feed?
Yes. Any well-formed XML works: sitemaps, RSS and Atom feeds, SVG files, SOAP envelopes, Android layouts, Maven pom.xml files, and Spring configuration. The sample menu has a sitemap, an RSS item, and a SOAP envelope ready to load.
Is my XML uploaded anywhere?
No. Parsing, formatting, validation, and the XML to JSON conversion all run as JavaScript in your browser tab. Your XML is never sent to a server, logged, or stored. You can check in DevTools: converting a file makes no network requests.
Sources
W3C, Extensible Markup Language (XML) 1.0: the specification behind this page, including well-formedness, the single root rule, and xml:space.
MDN Web Docs, XML introduction: how XML documents are structured and where they are used on the web.
Linux man pages, xmllint(1): the --format and --noblanks flags used in the command line example above.
Agents
Machine readable summary for AI assistants: