XML Formatter
Format, validate and minify XML without losing your declaration, DOCTYPE, or CDATA sections. Click any element or attribute for a smart XPath, or search the whole document in one click. Runs entirely in your browser.
Click any element or attribute to get its XPath, or use Search below.
Tips for Getting the Most Out of This XML Formatter
- Turn on Sort Attributes before diffing two versions of the same file. Attribute order has no semantic meaning in XML, but it makes a text diff noisy — sort both files first, then compare them in the Text Diff Checker.
- Use Strip Comments when preparing XML for a build pipeline or a clean diff — changelog notes and timestamps inside comments shouldn't count as real changes.
- Reach for Relative XPath by default. It survives reordering and re-pagination far better than Absolute, which breaks the moment a sibling element is inserted earlier in the document.
- Search before you scroll on a large file. The tree can be deep; Search finds a match by element name, attribute, or text content instantly, wherever it sits in the structure.
Features
Why XML Still Runs the Systems JSON Never Touched
JSON won the API layer, but XML never left the rest of the stack. SOAP web services still pass messages as XML envelopes. Android resource files — strings, layouts, manifests — are XML. Maven and Ant build configs are XML. RSS and Atom feeds are XML. Even modern Office documents are ZIP archives full of XML underneath. Anyone touching enterprise integration, legacy systems, or Android development runs into raw XML regularly, and reading it unformatted is genuinely painful — a SOAP response can nest six namespaces deep before the actual payload starts.
This formatter uses the same DOMParser the browser relies on internally, so well-formedness checking is exact, not approximate — the same rules that would reject a broken SVG or a bad RSS feed apply here, with a precise error message when something's wrong.
The Declaration and DOCTYPE Most Formatters Quietly Drop
Here's a detail that trips up nearly every browser-based XML tool: the DOM APIs that parse and re-serialize XML — DOMParser and XMLSerializer — don't expose the <?xml version="1.0"?> declaration through the normal document tree at all. Run a typical formatter on a document that starts with that line, and the output silently comes back without it. Same story for a <!DOCTYPE> declaration in older configs.
This tool works around both gaps deliberately: it captures the declaration from your original text before parsing even starts, and reattaches it to the formatted or minified result, while DOCTYPE nodes are serialized explicitly rather than skipped. What you get back is a faithfully re-indented version of what you pasted — not a document quietly missing its own prolog.
CDATA: Recognized as Its Own Node, Not Flattened to Text
A <![CDATA[...]]> section exists specifically so a chunk of embedded markup, script, or special characters can sit inside an XML document without needing to be escaped character by character — a common way to carry a snippet of HTML or raw JavaScript inside a config or feed file. The risk with a naive formatter is treating that section as ordinary text: re-serializing it would re-escape the very characters CDATA exists to protect, silently corrupting the embedded content the next time the file is read.
This formatter keeps CDATA as its own distinct node type all the way through — during parsing, in the tree view, and when writing the formatted or minified output back out — so a CDATA block round-trips as <![CDATA[...]]> exactly, never quietly reduced to escaped plain text along the way.
Well-Formed vs Valid — Two Different Bars
Well-formed is the syntax layer every parser enforces without exception: every opening tag has a matching close, elements nest correctly, attribute values are quoted, special characters are escaped, and there's exactly one root element. Fail this and no parser will touch the document at all. Valid is a separate, stricter layer on top — a well-formed document that also matches a specific schema (DTD or XML Schema) dictating which elements and attributes are allowed and where. A SOAP envelope has to follow a defined Envelope/Body structure; an Android manifest needs specific required attributes in specific places. This formatter checks well-formedness, which is the prerequisite everything else depends on — schema validation needs the schema document itself to check against.
Smart XPath: Relative Paths That Survive Reordering
Click any element or attribute in the tree and its XPath appears instantly below. Absolute mode walks from the document root using positional indexes — /bookstore/book[2]/title — which is precise but brittle: insert one book before it in the list, and the path now points at the wrong record. Relative mode instead looks at each ancestor for a stable identifying attribute — id, key, code, ref, and similar — and anchors to that instead, producing //book[@id='2']/title, which keeps pointing at the right node regardless of how the document is reordered or re-paginated.
Who Actually Opens an XML Formatter
Backend developers debugging a SOAP integration that just returned a fault code buried six namespaces deep. Android developers checking a manifest's permission block or a layout file's view hierarchy before a build. Build engineers navigating a Maven POM's nested plugin configuration. Anyone maintaining a feed pipeline who needs to confirm an RSS or Atom export is actually well-formed before it goes live.
From SOAP Debugging to Android Resources: Real Scenarios
A SOAP fault with no obvious cause. Paste the raw response, format it, and the namespace-heavy envelope structure becomes readable enough to find the actual fault string and detail elements without counting angle brackets by eye.
Auditing an Android manifest before release. Format AndroidManifest.xml to verify every permission declaration is intentional, or format a layout file to trace a view hierarchy that's rendering wrong on one screen size.
Comparing two config versions. Turn on Strip Comments and Sort Attributes, format both versions, and paste them into the Text Diff Checker — what's left is the actual change, not attribute-order or comment noise. If you need the data in JSON afterward, the XML to JSON converter picks up from here.
Everything Runs in Your Browser
SOAP responses carrying customer PII, config files with embedded database passwords and API keys, internal data feeds with proprietary business records — none of it is transmitted anywhere. Parsing, formatting, minifying, and XPath generation all run through the browser's native DOMParser and XMLSerializer, entirely on your device, and continue working offline once the page has loaded.
When XML Isn't the Right Format to Keep
If the destination is a modern REST API or a JavaScript front end, converting to JSON once and working with that from then on is usually less friction than round-tripping through XML repeatedly. This tool is also a well-formedness checker, not a schema validator — it confirms your XML parses correctly, not that it satisfies a specific XSD or DTD a downstream system might require. For genuine schema validation, a dedicated validator that loads the schema document is the right next step.