XML Formatter & Validator

XML's Sharp Edges: XXE and Entity Expansion

XML has a well-documented history of security issues that don't exist in simpler formats like JSON, and it's worth understanding them even when using a client-side formatter that isn't itself vulnerable. XML External Entity (XXE) injection abuses the <!DOCTYPE> and <!ENTITY> declarations that let an XML document reference external resources — a maliciously crafted document can define an entity that points at a local file path or an internal network address, and a vulnerable server-side parser configured to resolve external entities will fetch that resource and embed its contents into the parsed output, leaking local files or probing internal services the attacker couldn't otherwise reach. A related attack, sometimes called a "billion laughs" attack, defines a small number of entities that each reference several other entities, nesting exponentially so that a document only a few kilobytes in size expands to gigabytes in memory once fully resolved, exhausting server resources.

This tool uses the browser's built-in DOMParser, which — unlike many server-side XML libraries in their default configuration — does not fetch external entities over the network, making it safe to paste untrusted or unfamiliar XML here purely for formatting and validation. That safety property doesn't transfer automatically to whatever system actually consumes the XML in production: any server-side parser handling XML from an external source should have external entity resolution and DTD processing explicitly disabled, regardless of how this browser tool behaves.

Formatting Habits Worth Adopting

• Validate before you format, not after: confirm the document is well-formed first — an unclosed tag or unescaped ampersand produces a parse error that's far easier to fix while you still remember what you just edited than after several more changes have piled on top.
• Keep indentation consistent across a repository's XML files: mixed 2-space, 4-space, and tab indentation across Maven POMs or Spring configs in the same project makes diffs noisy and unreadable in code review — pick one indent width and apply it uniformly.
• Minify only at the point of transmission, never in source control: commit the readable, indented version to your repository and let a build step or a runtime library minify it if payload size actually matters — a minified XML file in version control is nearly impossible to review meaningfully in a diff.
• Preserve comments and processing instructions rather than stripping them during cleanup: a comment explaining an unusual configuration choice in a Jenkins or Spring XML file is often the only documentation of why that choice was made — losing it during a reformatting pass erases institutional knowledge for a purely cosmetic gain.

From SOAP Fault to Readable Structure

Legacy SOAP services frequently return error responses as a single unbroken line of XML, which is exactly the shape this tool is built to untangle. Consider a minified SOAP fault from a billing service: <soap:Envelope xmlns:soap="..."><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>Invoice not found</faultstring></soap:Fault></soap:Body></soap:Envelope> — technically complete and parseable, but functionally illegible at a glance. The formatter parses this with DOMParser, confirms it's well-formed, and re-serializes it with each element on its own indented line: soap:Envelope at the root, soap:Body nested one level in, soap:Fault nested inside that, with faultcode and faultstring appearing as clearly indented sibling leaves.

The actual error message — "Invoice not found" — which was buried in the middle of an unbroken string, becomes the first thing your eye lands on. If the input were instead malformed — say, a missing closing tag on soap:Fault — the parser would return a <parsererror> node instead of a usable document, which the tool surfaces directly as an error message rather than producing garbled or partial output.

Where Structured XML Review Pays Off

• Debugging a SOAP API integration: formatting a minified fault response to quickly locate the actual error code and message buried inside the envelope, rather than scanning an unbroken line of tags by eye.
• Reviewing a Maven POM before a dependency change: a large POM with many dependencies, profiles, and plugin declarations is far easier to scan for a version conflict once properly indented than in its original, often inconsistently formatted state.
• Auditing CI/CD pipeline configuration: Jenkins pipeline definitions, TeamCity build configs, and MSBuild project files stored as XML benefit from clean formatting when reviewing a change to build logic in a pull request.
• Sanity-checking hand-edited configuration before deployment: confirming a manually edited Spring application-context file or Android manifest is still well-formed after a quick edit, before it reaches a build pipeline that would otherwise fail on a typo far from where it was introduced.

Frequently Asked Questions