XML Formatter — Free Pretty Printer Online

XML refuses to die: configuration files, SOAP APIs, RSS feeds, Office documents, SVG graphics, and sitemaps all still speak it. And XML has a habit of arriving as a single unbroken line — thousands of characters with no whitespace — because machines do not need readability. Humans, unfortunately, do.

Pretty-printing restores the document’s structure: each element on its own line, children indented under parents, so the hierarchy you can feel but not see becomes obvious. It is the difference between spotting a misnested tag in seconds versus hunting through a wall of angle brackets.

This free XML formatter parses your document with the browser’s native XML parser and re-emits it with clean two-space indentation. Because it truly parses (not just regexes line breaks), it also validates: malformed XML produces a plain-language error instead of silently “formatted” garbage.

How to use the XML formatter

1. Paste your XML — a snippet, a config file, or an API response.
2. Click “Format XML” (or “Load sample” to try it first).
3. Read the indented output — nested elements now reveal the document tree.
4. Copy the result into your editor or documentation.
5. If there is an error, read the message — it usually points at the exact problem, like an unclosed tag.

Key features & benefits

• Real parsing, not regex. The browser’s XML parser builds the document tree, so indentation reflects true structure.
• Plain-language errors. Mismatched tags, unclosed elements, and bad entities are reported readably.
• Two-space indentation. A widely standard indent that stays compact even for deeply nested documents.
• Attributes preserved. All attributes keep their names, values, and order on the opening tag.
• Comments and CDATA kept. <!-- --> comments and CDATA sections survive formatting intact.
• Self-closing tags normalized. Empty elements render as <tag/> for a tidy, consistent look.

Debugging malformed XML

Most XML errors fall into a small set of patterns. Here is how to recognize and fix them.

Unclosed or mismatched tags

<name>value</naem> — a typo in the closing tag — is the classic. The parser error names the offending line; fix the spelling and re-format. Remember that XML, unlike HTML, is case-sensitive and every tag must close. For large documents, our regex tester can locate every occurrence of a suspect tag name.

Unescaped special characters

A raw & or < inside text content breaks parsing. They must be written as & and < — our HTML entity encoder/decoder converts them in seconds. This is the most common error in hand-written XML.

Multiple root elements

A well-formed XML document has exactly one root. Two sibling top-level elements is not valid XML — wrap them in a single container element. If you are comparing XML against JSON APIs, our JSON formatter gives JSON the same pretty-print treatment.

Frequently asked questions

How It Works: Under the Hood

XML formatting requires a real parse, not text manipulation. The formatter builds a document tree: elements become nodes, attributes attach to their elements, text content and CDATA sections become leaf nodes, and comments/processing instructions are preserved as their own node types. Only with this structural understanding can it correctly indent nested elements, align attributes, and wrap long text — a regex-based “formatter” would indent the <table> inside a CDATA block or a code sample, corrupting the data.

The key formatting decisions: indentation width (2 spaces is the modern default; tabs are valid but divisive), attribute layout (one per line for elements with many attributes vs inline), empty elements (<tag/> vs <tag></tag> — semantically identical, stylistically different), and text wrapping (whether long text nodes get line-broken, which can alter whitespace-sensitive content).

Namespaces add complexity: <xsl:template> and <svg:rect> belong to different vocabularies, and the formatter must preserve prefix bindings without “helpfully” consolidating them. A formatter that strips or rewrites namespace declarations produces XML that looks clean and fails validation.

Real-World Use Cases

• Debugging SOAP/API responses: a developer pastes a 2MB single-line XML response from a legacy API, formats it, and immediately sees the nested structure hiding the missing field.
• Editing config files: a DevOps engineer formats a sprawling Maven pom.xml or Android manifest before editing — making the change in a readable file instead of a minified wall.
• Comparing XML documents: two config files that “should be identical” get formatted with identical settings first — only then does a diff show real differences instead of whitespace noise.
• Preparing XSLT input: an integration developer formats a sample feed to understand its nesting before writing the XSLT transform, catching the wrapper elements that would have broken their XPath.
• Documentation: a technical writer formats example API payloads for docs — readers can actually follow the structure instead of scrolling horizontally through minified XML.

Advanced Tips

• Validate before formatting: run well-formedness checking first. Formatting invalid XML (unclosed tags, bad nesting) can produce confidently-formatted garbage that hides the original error — fix structure first, prettify second.
• Protect whitespace-sensitive content: if your XML contains xml:space=”preserve” or preformatted text (code samples, poetry), ensure the formatter respects it — aggressive text rewrapping corrupts this content silently.
• Standardize before diffing: when comparing XML from two systems, format both with identical settings (same indent, same empty-element style). Otherwise every line diffs and the comparison is useless.
• Keep a minified copy for production: formatted XML is for humans; wire formats should stay minified. Format a copy for reading — don’t deploy the pretty-printed version and pay the bandwidth cost forever.

Common Mistakes to Avoid

• Formatting XML with HTML tools: HTML parsers “fix” things XML forbids (unclosed tags, case-insensitivity) — running XML through an HTML formatter can silently alter the document’s meaning. Use an XML-aware tool.
• Ignoring encoding declarations: if the XML declares encoding=”ISO-8859-1″ but your editor saves UTF-8, special characters corrupt on the next read. Match the declared encoding or update the declaration.
• Breaking CDATA sections: content inside <![CDATA[…]]> must pass through byte-identical. A formatter that re-indents or entity-encodes CDATA contents destroys embedded scripts or HTML samples.
• Assuming formatted = valid: pretty indentation says nothing about schema validity. A beautifully formatted document can still violate its XSD — formatting and validation are separate steps, always.

Validating Before You Deploy

An unformatted config file is annoying; an invalid one is a production incident. Because this tool truly parses your XML with the browser’s native parser — not just regexes line breaks — it validates as it formats: mismatched tags, unclosed elements, and bad entities produce plain-language errors instead of silently ‘formatted’ garbage. Run every config file, SOAP payload, and sitemap through it before deployment and catch the typo that would have broken the build at 2 a.m. API responses in JSON get the same safety net from the JSON formatter.

Pretty-Print vs Minify: Picking the Right One

Pretty-printing and minifying serve opposite masters. Pretty-print when humans will read the file — debugging, code review, documentation — because indentation reveals the document tree and misnested tags announce themselves. Minify when machines consume it and every byte counts over the wire. This tool pretty-prints with clean two-space indentation, normalizes empty elements to self-closing tags, and preserves attributes, comments, and CDATA. Converting structured content for docs? The HTML to Markdown converter handles that trip.