XML Formatter / Validator
Format, beautify and validate XML with customizable indentation.
Reviewed by Aygul Dovletova · Last reviewed
How to Use the XML Formatter
- Paste your XML into the input pane. A full document with an XML declaration, a SOAP envelope, an Atom feed, or a configuration file like a Maven
pom.xmlall work. - Select an indent: two spaces, four spaces, or a tab character. The Format button uses that setting on its next run.
- Click Format for an indented tree view, Minify to collapse into a single line, or Validate to check that the document is well-formed per the XML 1.0 specification.
- Review the result in the output pane. If validation fails, the error banner reports the line and column of the problem so you can jump back to fix it.
What It Does and How
The tool builds a real DOM tree with the browser's native DOMParser using the application/xml MIME type. That means validation piggybacks on the same parser Chrome, Firefox, and Safari use to handle XML in XHR responses and in fetch(), so well-formedness rules (matching tags, properly escaped entities, correct attribute quoting) behave exactly as they would in an actual XML pipeline. Once the parse succeeds, the formatter performs a depth-first traversal and emits each element with indentation equal to its tree depth.
Text nodes preserve their content verbatim between tags; whitespace-only text between elements is discarded during pretty-printing so the tree is visually clean. Processing instructions (<?xml-stylesheet ...?>), CDATA sections, and comments are kept on their own lines. Minification runs the inverse pass - the same DOM tree is serialised back without indentation. Because a parse is required, this tool actively rejects malformed documents rather than guessing at repairs, unlike HTML which has documented recovery rules.
When This Tool Earns Its Keep
- Debugging a SOAP request or response where the server returned everything on one line.
- Reading a Maven, Ant, or Gradle build file that has accumulated years of edits without consistent indentation.
- Inspecting an RSS or Atom feed copied from
curlto understand its structure. - Validating an SVG file before embedding it in a design system - SVG is XML, so the same rules apply.
- Normalising the output of an XML template engine before committing it to version control.
- Preparing a concise minimum repro XML snippet when filing a bug against a parser or serialiser.
Edge Cases to Watch For
- Namespaces. Prefixes like
xsi:orsoap:are preserved exactly as they appear. If your source mixes declared and undeclared namespaces, the parser will reject it - that is a real well-formedness error per XML 1.0. - Whitespace-sensitive content. XML has an
xml:space="preserve"attribute that tells parsers to keep text content byte-for-byte. The current formatter does not honour it; if you need preservation, keep your source indented manually. - Entity references. The five predefined entities (
&,<,>,",') round-trip correctly. Custom entities declared in an internal DTD may be resolved or preserved depending on the browser. - Mixed content. When an element contains both text and child elements (
<p>Hello <b>world</b>!</p>), the pretty-printer keeps the children on separate lines but may alter the spacing between text and tags. Minify is lossless for mixed content. - Encoding. The input is assumed to be UTF-8. If your source declares a different encoding (
<?xml version="1.0" encoding="ISO-8859-1"?>) you may need to convert to UTF-8 first.
XML Specification Background
XML is defined by the W3C Extensible Markup Language 1.0 Recommendation (plus errata) and the later XML 1.1 revision that handles additional Unicode characters. The spec is strict in a way HTML is not: every opening tag requires a matching close, attribute values must be quoted, and the five predefined entities are the only implicit ones. Well-formedness is a baseline; validity against a DTD or XML Schema (XSD) is a stronger additional check that this tool does not perform. The XML declaration and encoding pseudo-attribute are defined in section 2.8, and the rules for processing instructions and comments sit in section 2.6. Namespaces are defined in a separate spec, Namespaces in XML 1.0.
Comparisons
Command-line xmllint --format (part of libxml2) is the reference pretty-printer in the Unix world and supports DTD validation, XPath queries, and XInclude processing. If you have libxml2 installed, it is strictly more capable. xmlstarlet layers ergonomic queries on top of the same library. IntelliJ, VS Code with the XML extension, and Oxygen XML Editor all offer format-on-save with schema awareness. This web tool is for the moments when none of those are in reach - SSH boxes without libxml2, phones, locked-down work laptops - and for quick validation of pasted snippets without saving anything to disk.
Frequently Asked Questions
Which XML parser does the tool use?
It uses the browser-native <code>DOMParser</code> with the <code>application/xml</code> MIME type. That means Chrome and Edge go through Blink, Firefox through Gecko, and Safari through WebKit. Each engine implements the same XML 1.0 well-formedness rules, so a document that parses here will generally parse in any other XML consumer. Validation messages may differ slightly between engines because each writes its own error text.
Can it validate against a DTD or an XML Schema?
No. Validation is limited to well-formedness, which is the XML 1.0 baseline - tags are balanced, attributes are quoted, entities are declared. Checking against a Document Type Definition or an XSD requires schema-aware parsers like <code>xmllint</code>, <code>xmlstarlet</code>, or Java's <code>javax.xml.validation</code> API. Use those in a build step if contract validation matters.
Why does my SOAP envelope fail to format?
The most common cause is a namespace prefix that has not been declared. Many SOAP examples in blog posts strip the <code>xmlns:</code> declarations for brevity, and the browser parser rejects such documents. Make sure every prefix used in an element or attribute name has a matching <code>xmlns:prefix="..."</code> on an ancestor. The error message will include the offending prefix.
Does validation check the encoding declaration?
No, because by the time the XML reaches the browser it has already been decoded as a JavaScript string. The declared encoding in <code><?xml version="1.0" encoding="..."?></code> is ignored at this layer. If you need to verify that a source file matches its declared encoding, run <code>xmllint --encode</code> or check with <code>file(1)</code> on the command line before pasting.
Is my XML sent to a server for parsing?
No. <code>DOMParser</code> is a synchronous, in-process API and every action stays inside your tab. There is no network call, no websocket, and no storage written to IndexedDB or localStorage. You can open DevTools Network panel, click Format, and watch it record zero new requests. The input and the parsed DOM exist only in the tab's memory and are released when you reload the page.
Will formatting break my signed XML document?
Yes, if the signature covers the serialised bytes. XML digital signatures canonicalise the document before hashing precisely because pretty-printing changes byte sequences without changing structure. If a document has an embedded <code><Signature></code> element, reformat it only for inspection and re-sign with the original canonicalised form. Use the Minify operation to get a single-line version that is likely closer to the canonical form but still not guaranteed.
Does it handle CDATA sections correctly?
Yes. <code><![CDATA[ ... ]]></code> blocks are preserved verbatim. That matters because CDATA commonly wraps embedded scripts, SQL fragments, or HTML that would otherwise need to be entity-encoded. The parser treats the CDATA as a single text node and the serialiser reproduces it unchanged.
Can I paste an HTML document and format it here?
It will fail unless your HTML is strict XHTML - every tag closed, attributes quoted, void elements self-closed. Real-world HTML uses omitted close tags and unquoted attributes, which are legal in HTML but not in XML. Use the HTML Formatter tool for HTML input; this tool expects documents that would pass an XML parser.
What is the largest XML document this can handle?
Browsers will comfortably parse files up to several megabytes through <code>DOMParser</code>. Very large documents (tens of megabytes, common with dataset exports from NCBI or Wikipedia) can exhaust tab memory and freeze the page. For those workloads switch to streaming parsers like <code>lxml</code> in Python or SAX-based tools that never build the full DOM in memory.
Does the minifier preserve the XML declaration?
Yes. The <code><?xml version="1.0" ... ?></code> processing instruction is emitted first in the minified output, as required by the spec. Any leading comments or processing instructions before the root element are preserved in the same order. The output is a valid well-formed XML document ready to send over the wire.
More Developer Tools
Base64 Encoder & Decoder
Encode UTF-8 text to Base64 online or decode Base64 back to UTF-8 and plain text. Runs in your browser with no upload.
Open toolBulk URL Encode / Decode
Encode or decode many URLs at once. Paste a newline-separated list and the tool processes each line in parallel, preserving order and blank lines.
Open toolCode Screenshot
Create beautiful code snippet images with customizable themes.
Open toolColor Converter
Convert colors between HEX, RGB, HSL and CMYK formats.
Open toolCron Expression Parser
Parse cron expressions into human-readable schedules with next run times.
Open toolCSS Formatter / Minifier
Format, beautify and minify CSS code.
Open tool