XML Formatter
Format, beautify, minify, and validate XML documents online. Pretty-print with a custom indent size, check well-formedness with exact line/column error reporting, and preserve comments, CDATA sections, and mixed content exactly as written.
XML Input
Formatted Output
Formatted XML will appear here
About XML Formatter
This tool validates well-formedness and then beautifies or minifies XML entirely in your browser — no upload. Comments, CDATA sections, processing instructions, and the XML declaration are preserved verbatim, and text inside mixed-content elements is never reflowed, so formatting can't change your document's meaning. Note that it checks well-formedness only, not validity against a DTD or XSD schema.
About XML Formatter
An XML formatter and beautifier that re-indents XML documents for readability, minifies them for transmission, and checks well-formedness before doing either. Unlike formatters built on DOMParser, this tool uses a tokenizer that only touches whitespace-only gaps between tags — comments, CDATA sections, processing instructions, the XML declaration, and any text content (including mixed content) are copied through byte-for-byte, so formatting never changes what the document means.
Why use a XML Formatter?
Readable, consistently-indented XML is dramatically easier to review, diff, and debug than a single-line SOAP response or a config file exported without formatting. Beautifying surfaces structural problems (a misplaced closing tag, an unexpectedly deep nesting level) at a glance. Minifying does the opposite — it strips insignificant whitespace to shrink payloads for transmission or storage. Validating first means you find out about a truncated response or a stray unescaped ampersand immediately, with the exact line and column, instead of debugging a confusing downstream parser error.
Who is it for?
Useful for backend and integration developers debugging SOAP/REST XML payloads, API designers reviewing request/response bodies, developers cleaning up XML config files (Maven POMs, Spring configs, Android manifests, RSS/Atom feeds) for code review, and anyone who received a minified XML export and needs to actually read it before working with the data.
How to use the tool
Paste your XML into the input box, or switch to 'Upload File' and drop in a local .xml file
Choose 'Format (Beautify)' mode and pick an indent size — 2 spaces, 4 spaces, or Tab
Click the action button to validate and pretty-print the document — well-formedness is checked automatically before formatting
If the XML isn't well-formed, read the error message for the exact line and column, which is also highlighted in the input box
Fix the reported issue (an unclosed tag, an unescaped '&', a second root element) and click the action button again
Switch to 'Minify (Compress)' mode and click the action button to strip whitespace between tags for the smallest possible payload
Check the character and line counts under each panel to see how much the output shrank or grew
Copy the result to your clipboard or download it as a .xml file
Click 'Load Sample XML' to see how comments, a CDATA block, a namespaced element, and inline mixed content all survive formatting untouched
Frequently Asked Questions
How do I format, beautify, and validate XML online?
Paste XML into the input panel or upload a .xml file, choose an indent size (2 spaces, 4 spaces, or Tab), and click the format button. The tool first checks well-formedness — if the document is invalid, you get an error with the exact line and column instead of a formatted result. If it's valid, every element is placed on its own line and indented by nesting depth, while comments, CDATA sections, the XML declaration, and any mixed text content are preserved exactly as written. Copy the output or download it as .xml. Switch to Minify mode to do the reverse: strip all whitespace between tags for the smallest possible payload.
Does this tool check whether my XML is truly valid, or just well-formed?
Just well-formed — and it's worth being precise about the difference. Well-formedness (what this tool checks) means the document follows XML's own syntax rules: exactly one root element, every tag properly closed and nested, attribute values quoted, special characters like '&' and '<' escaped. Validity is a separate, stronger check against a DTD or XSD schema — e.g. 'does every <price> element contain a decimal number?' This tool does not parse or check against a DTD/XSD. For schema validation, use a dedicated XSD/DTD validator or your XML library's schema-validation API (libxml2, Java's javax.xml.validation, lxml with XMLSchema).
Is my XML data sent to a server when I format or validate it?
No. Both validation and formatting run entirely in your browser via JavaScript — well-formedness checking uses fast-xml-parser's validator compiled into the page's client bundle, and the pretty-printer is plain JavaScript string processing. Your XML never reaches a server, never gets logged, and never leaves your device. Verify this yourself in DevTools' Network tab: clicking Format or Minify produces zero HTTP requests. This makes the tool safe for proprietary SOAP payloads, internal configuration files, or any XML containing data you wouldn't want a third party to see.
Should I minify or beautify my XML?
Beautify during development and review: readable, indented XML is what you want when diffing a config change in a pull request, debugging a SOAP response in DevTools, or explaining a document's structure to a teammate. Minify for transmission and storage: stripping whitespace between tags reduces payload size, which matters for high-volume APIs, mobile clients, or XML stored in a database column. The two are inverses and produce semantically identical documents — minifying never removes anything from a real text node, only the insignificant whitespace between tags. Most pipelines beautify for humans and minify right before sending over the wire.
Why doesn't the formatter reindent the text inside elements like <note>?
Because whitespace inside 'mixed content' — an element containing both text and child elements, like <p>Hello <b>world</b>!</p> — is significant: it's part of the data, not decoration. XML even has a reserved xml:space attribute (values 'default' or 'preserve') precisely because whitespace significance is sometimes ambiguous and needs to be stated explicitly. Rather than guess, this formatter only ever inserts or removes whitespace in gaps between tags that already contain nothing but whitespace. Any gap containing real text is left completely untouched, so a formatted document is guaranteed to mean exactly what the original did — no accidental word-merging or lost spacing.
What's the difference between a CDATA section and escaping characters like < and &?
Both let you include characters XML would otherwise treat as markup, but they work oppositely. Escaping replaces individual special characters with entity references: '&' becomes '&', '<' becomes '<'. It works everywhere but gets unreadable fast for content with lots of markup-like text. A CDATA section — <![CDATA[ ... ]]> — tells the parser 'treat everything in here as literal text, don't interpret any of it,' which is convenient for embedding a snippet of HTML, JSON, or script inside an XML feed without escaping every angle bracket. The one restriction: a CDATA section can never contain the literal sequence ']]>', since that's how the parser finds its end, and CDATA sections cannot be nested.
What does the XML declaration do, and are self-closing tags the same as empty tags?
The XML declaration — <?xml version="1.0" encoding="UTF-8"?> — is optional but, when present, must be the very first thing in the document. It states the XML version (almost always 1.0) and the character encoding used to interpret the byte stream; get the encoding wrong and every non-ASCII character in the file misdecodes. On self-closing tags: <tag/> and <tag></tag> are equivalent per the XML specification — both represent an empty element with no content. The one practical gotcha is downstream: some XML-to-JSON converters (including this site's [XML to JSON](/tools/xml-to-json/) tool) may represent an explicitly-empty <tag></tag> as an empty string and a self-closed <tag/> as null, so check your converter's behavior if that distinction matters to your pipeline.
What are the most common XML errors, and how do I fix them?
Three account for most well-formedness failures. (1) Unclosed or mismatched tags — every opening tag needs an exact matching closing tag, properly nested (no <a><b></a></b> crossing); the validator reports the line where it expected a specific closing tag and got another. (2) Unescaped ampersands — a literal '&' in text must be written as '&' unless it's already starting a valid entity reference; 'Tom & Jerry' is invalid, 'Tom & Jerry' is valid. (3) Multiple root elements — XML documents allow exactly one top-level element; a second sibling after the first closes is rejected. Once your XML is clean, convert it with [XML to JSON](/tools/xml-to-json/) or [XML to CSV](/tools/xml-to-csv/), or compare formatting approaches with [JSON Formatter](/tools/json-formatter/) and [HTML Formatter](/tools/html-formatter/).
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.