How do you use this tool?
- Paste your XML into the input panel, or click 'Upload' to load an XML file from your computer.
- Choose your indentation style: 2 spaces, 4 spaces, or tabs.
- Click 'Format' to prettify. Any well-formedness errors appear inline with line numbers.
- Review the formatted output. Syntax errors are highlighted in red with a plain-English explanation.
- Click 'Copy' to copy the result to your clipboard, or 'Minify' to collapse the XML back to a single line for production use.
What This Tool Does
This XML formatter takes any XML string — minified, manually edited, or machine-generated — and outputs clean, consistently indented XML. It simultaneously validates well-formedness, so structural errors (unclosed tags, mismatched nesting, illegal characters) are caught before the XML reaches a parser, API, or build pipeline.
The formatter also runs in reverse: paste formatted XML and click ‘Minify’ to collapse it to a single line for embedding in JSON payloads, HTTP requests, or environments where whitespace adds unnecessary bytes.
How It Works
Modern browsers include a built-in DOMParser that parses XML natively. This tool feeds your input to DOMParser with the application/xml MIME type. If the parser returns an error document (parsererror), the tool extracts the line number and error message and displays them inline. If parsing succeeds, the tool traverses the resulting DOM tree and serializes it with clean indentation using a recursive depth-first walk.
This approach is fast, dependency-free, and identical in behavior to the XML parsers used in production environments — meaning the well-formedness check here reflects what a real parser will do.
What Are Common XML Formats by Industry?
| Format | Common In | Typical Issue |
|---|---|---|
| SOAP envelopes | Enterprise APIs, banking, insurance | Machine-generated, zero whitespace |
| RSS / Atom feeds | News, podcasts, blogs | Mixed quoting styles, loose nesting |
| Maven POM | Java / Spring projects | Deep nesting, hard to diff |
| Android manifest | Mobile development | Complex namespace declarations |
| Salesforce metadata | CRM configuration | Long single-line files from CLI export |
| SVG | Design exports | Unreadable after Figma/Illustrator export |
| XLIFF | Localization files | Large, deeply nested translation pairs |
What Are Common Use Cases?
Debugging SOAP API responses. SOAP services return XML responses that are typically minified or single-line. Pasting the response here makes it immediately readable, letting you locate the specific element causing an error without manually counting brackets.
Reviewing RSS or Atom feeds. Feed URLs return raw XML. Format it here to confirm your <item> or <entry> elements are correctly structured, that CDATA sections are valid, and that the feed will parse correctly in aggregators.
Cleaning up Android manifest files. AndroidManifest.xml files in large projects accumulate inconsistent formatting over time. Running the file through this formatter standardizes indentation before code review or merge, reducing noise in diffs.
Pre-commit validation for configuration XML. Maven POM files, Spring XML configs, and Ant build files are XML. Validating well-formedness before a commit prevents CI pipeline failures caused by a missing closing tag or unescaped & character.
Minifying XML for API payloads. Some REST APIs accept XML request bodies embedded in JSON strings. Minifying the XML first reduces payload size and eliminates escaping complications caused by newlines in JSON strings.
Cleaning up localization files. XLIFF (.xlf) files used in iOS, Android, and web localization are XML. Formatting them makes it easier to spot untranslated segments or malformed translation units.
Frequently Asked Questions
What characters need to be escaped in XML?
The five predefined XML entities are: & for &, < for <, > for >, " for " inside attribute values, and ' for ' inside attribute values. Forgetting to escape an & character in element content is one of the most common XML well-formedness errors.
Why does my XML look correct but the validator still fails?
Common hidden issues: a byte-order mark (BOM) at the start of the file, Windows line endings causing parsing problems in strict parsers, or a character encoding declared in the XML declaration (<?xml encoding="UTF-8"?>) that doesn’t match the actual encoding. Pasting the content directly (rather than uploading) eliminates most encoding issues.
Can I validate against an XSD schema?
Not in this browser-based tool — schema validation requires loading the XSD and running a validation pass against it, which is beyond what the browser’s DOMParser supports. For XSD validation, use xmllint (xmllint --schema schema.xsd file.xml) or an IDE with XML schema support.
Last updated: