By Stephen Milner · UtilityForge · Last reviewed: May 2026
Format / Prettify adds consistent 2-space indentation and one element per line. Preserves CDATA sections, comments, namespaces, and processing instructions exactly as they appear in the original.
Minify removes all whitespace between tags and strips comments. Self-closes empty elements. Produces the smallest valid representation of the same document.
Validate checks well-formedness: balanced tags, proper nesting, quoted attributes, and correct escaping. Reports the exact line and column of any error.
Privacy: everything runs locally in your browser using the native DOMParser API. No XML is sent to any server. Safe to use with internal configs, SOAP responses, or sensitive data.
XML Formatter & Validator is a browser-based tool that takes raw, compressed, or malformed XML and either prettifies it with consistent indentation, strips it down to its smallest possible form, or checks whether it is well-formed. Nothing is sent to a server. The entire operation runs in your browser using the native DOMParser API.
The tool is built for the people who deal with XML daily: developers debugging SOAP API responses, QA engineers validating config files, data engineers inspecting large feed exports, and system integrators who receive XML from third-party systems and need to understand its structure at a glance.
Formatting is what you reach for when you need to read XML. Compressed XML is nearly impossible to read as a single line. Think SOAP responses, serialised objects from legacy APIs, or data feeds from suppliers. Formatting adds two-space indentation, one element per line, and structures nested content so you can visually trace the hierarchy. This tool preserves all content during formatting: CDATA sections, XML comments, processing instructions, namespace declarations, and special characters are all handled correctly.
Minifying is the reverse operation. You use it before storing XML in a database column, sending it over a network where byte count matters, or embedding it in a system that rejects whitespace in certain positions. Minification removes XML comments, self-closes empty elements (turns <foo></foo> into <foo/>), and collapses all whitespace-only text nodes. The result is the smallest possible representation of the same document.
XML has a strict definition of well-formedness, distinct from schema validity. A well-formed XML document must:
<, >, &, ", ') in text content and attribute valuesThe Validate button checks these rules. It does not validate against an XSD schema or DTD. It confirms structural correctness only. If you receive a "Valid XML" result, the document can be safely parsed by any standards-compliant XML parser. If you receive an error, the line and column number tell you exactly where the parser got stuck.
The error messages produced by XML parsers are often terse. Here are the most common ones and what they mean in practice.
"Opening and ending tag mismatch": a closing tag does not match the most recent open tag. Common causes are a copy-paste error that duplicated a tag name, a typo, or a manually edited file where a rename was only applied to one side.
"Extra content at the end of the document": XML requires exactly one root element. If your document has two top-level elements with nothing wrapping them, the parser accepts the first and rejects everything after it. The fix is to add a wrapper root element.
"Undeclared entity reference": a &something; entity reference appears that is not one of the five built-in XML entities (&, <, >, ", '). HTML entities like are not valid in XML unless declared in a DTD. Replace them with numeric character references (  for non-breaking space).
"Attribute without value": HTML allows bare attributes (<input disabled>), but XML does not. Every attribute must have an explicit value: <input disabled="disabled"/>.
"Document is empty": the input contained only whitespace or was entirely blank. A common result of copying a URL instead of the XML content, or a fetch that returned an empty response.
XML is sometimes described as a legacy format, but it remains deeply embedded in the infrastructure of many industries. SOAP web services are still dominant in banking, insurance, healthcare, government APIs, and ERP integrations. They all produce XML. Maven build files are XML. Android layout files, Office Open XML (.docx, .xlsx), SVG, MathML, Atom/RSS feeds, sitemap.xml, and countless configuration formats are XML.
Developers working at the edges of these systems reach for an XML formatter several times a week. The alternative, reading minified XML in a text editor, costs time and introduces error.
Every operation runs entirely in JavaScript inside your browser tab: formatting, minification, validation, and syntax highlighting. No data is transmitted to any server. You can paste SOAP responses containing PII, internal config files, or proprietary data feeds and be confident that the content does not leave your machine.
Well-formed XML follows the structural rules of the XML specification: one root element, balanced and properly nested tags, quoted attribute values, and correct escaping of reserved characters. Any conforming XML parser can read a well-formed document. Valid XML goes further. It also conforms to a schema (XSD, DTD, or RelaxNG) that defines which elements and attributes are allowed, their order, and their data types. This tool checks well-formedness only. Schema validation requires a schema definition and a more specialised tool.
Some applications and parsers use lenient, non-standard XML parsing that accepts technically malformed input: missing closing tags, unescaped ampersands, bare attributes without values. This tool uses strict W3C XML parsing via the browser's native DOMParser. If your XML fails here but succeeds in a specific application, the application is accepting invalid XML as a convenience, not because the XML is correct. The strictest definition is always the safest to follow.
Yes. Namespace declarations (xmlns:prefix="uri") are standard XML attributes and are preserved exactly as-is during formatting and minification. Element names with namespace prefixes (e.g., <soap:Body>) are also preserved and coloured as regular tag names in the highlighted output.
CDATA sections (<![CDATA[ ... ]]>) are preserved intact during formatting. Their internal whitespace is not modified, since CDATA content is treated as raw text. During minification, CDATA sections are preserved as-is but whitespace-only CDATA blocks are dropped.
The tool accepts files up to 2 MB via the Upload button. Very large formatted files (over 300 KB) are displayed without syntax colouring to keep the browser responsive. For files larger than 2 MB, a dedicated desktop XML editor such as Oxygen XML or VS Code with an XML extension is more appropriate.
2 MB. This covers the large majority of real-world XML use cases including sizeable SOAP envelopes, Android layout files, Maven POMs, and data feed exports. Files approaching or exceeding this size that require frequent editing are better handled with a desktop tool.
The minifier converts empty elements (those with no child nodes and no text content) to self-closing form: <item></item> becomes <item/>. This is semantically equivalent in XML (unlike HTML) and reduces byte count. If a receiving parser requires the expanded form, you will need to post-process the output.
Yes, comments are preserved during formatting and indented with the surrounding content. During minification, comments are stripped entirely, since they serve no machine-readable purpose in a minified payload.
File uploads may include a UTF-8 BOM (EF BB BF). The browser's FileReader API strips the BOM before passing the text to the tool, so BOM-prefixed files parse correctly. If you paste XML from a source that includes a visible BOM character at the start, remove it manually before processing.
Yes. Once the page has loaded, all three operations (format, minify, validate) work without a network connection. The DOMParser API is built into every modern browser. No external scripts or APIs are called when you click Format, Minify, or Validate.