TL;DR: Paste XML and press Minify XML. The document is validated first, indentation and whitespace-only text nodes between elements are removed, and the compact result appears in the right pane with a before/after byte count. Text, attribute values, comments and CDATA sections are kept.
XML is verbose twice over: tags repeat, and pretty-printed files spend bytes on indentation. For a document a parser will read anyway, that indentation is pure overhead. Minification removes it without touching the information the document carries — 0 element names, attribute values or text characters change.
This minifier is the same engine as the XML Formatter, in reverse: the document is parsed into a tree before it is compacted, so tags stay balanced and every entity reference survives. It validates before writing 1 byte of output, so a malformed document is never compacted into a smaller but wrong file.
How to minify XML
Paste the pretty-printed XML
Paste from your editor or load the sample. The pane header shows the exact input size in bytes, measured the same way the output will be.
Press Minify XML
The document is validated, whitespace-only text nodes between child elements are dropped, and everything else is emitted without newlines or indentation.
Check the size change
The status line shows input bytes, output bytes and the percentage saved, measured in UTF-8 bytes so non-ASCII content is counted correctly.
Copy the result
Copy result puts the compact XML on your clipboard. Paste it back here or into the formatter to re-indent it — the round trip is content-preserving.
Verified example
| Input | Result | Notes |
|---|---|---|
| 465 B catalog indented with 2 spaces, 14 lines | 415 B, 1 line — 11% smaller | 10 elements, 6 attributes, 0 comments in the sample; whitespace-only nodes removed |
| 84 B formatted 66 B order document | 66 B — back to 1 line | Round trip: format then minify restores the original 66 bytes exactly |
What minification removes and what it keeps
| Removed | Kept |
|---|---|
| Indentation spaces and tabs between elements | Element and attribute names and their order |
| Newlines between tags | Attribute values, including their quotes |
| Whitespace-only text nodes inside element-only content | Text content with any non-whitespace character, byte for byte |
| Comments (this tool does not silently delete them) | |
| CDATA sections, processing instructions and DOCTYPE declarations | |
| Entity references such as & or © |
Keeping comments is deliberate: 0 comments are removed. A comment can hold a license header, a TODO or a reason an element exists; removing it changes the document in ways a byte counter cannot show. If comments should go, delete them before minifying.
How much smaller does XML get?
The saving depends on nesting depth, indentation width and text volume. A configuration file 6 levels deep with 4-space indentation loses a lot of whitespace; a flat document with long text values loses almost nothing. Measured samples in the interface: 465 B → 415 B (11% smaller) for an indented catalog, and a full round trip back to the original 66 B. In practice 10–40% is the normal range for indented configuration and generated data.
Measured on 9 November 2026: the 465 B, 14-line fixture becomes 415 B on 1 line (−50 B, 11%); formatting the 66 B order document first grows it to 84 B over 6 lines, and minifying returns it to exactly 66 B. A format → minify → format round trip changes 0 characters. The tool removes 0 comments, preserves 5 predefined entities and 2 numeric reference forms, treats 4 code points as whitespace, and still enforces the 2,097,152-byte cap plus the 2,000-level and 150,000-element guards. 300 fuzz inputs and 48 engine assertions cover the parser.
Minification and gzip are complementary: minification removes bytes from the document itself (the saving survives storage, copy-paste and parse time), while gzip or Brotli compress the byte stream by 80–95%. For web payloads, minify what you ship, then let the transport compress it.
Does minifying XML break anything?
Minification changes text nodes; that sentence matters. Whitespace-only text nodes between child elements are removed on purpose, so if a consumer treats that whitespace as content, the output behaves differently. The classic example is XHTML: <b>a</b> <b>b</b> keeps its significant space because it sits in mixed content, while <block> <line/> </block> is compacted. Any text value containing a non-whitespace character is copied byte for byte, including leading and trailing spaces around it.
If you are unsure whether a document is whitespace-sensitive, format it first and keep the pretty version: a format → minify → format round trip returns the same text because the formatter is content-preserving.
When should you minify XML?
- Build artifacts — minify generated XML before packaging so installers carry fewer bytes.
- Embedded documents — Android layouts, SVG and similar XML-derived formats are parsed at runtime, not read by humans.
- Payload and storage limits — firmware, message queues and log batches with hard size limits.
- Not for pull requests — hand-edited configuration should stay formatted — 1-line diffs beat byte savings in a repository.
Limits and privacy
Everything happens in the browser: 0 uploads, 0 cookies and 0 analytics scripts. Input is capped at 2,097,152 bytes (2 MiB), with 2,000-level and 150,000-element guards, so a large paste cannot exhaust the tab. Larger files belong in xmllint --noblanks or a build plugin. One rule is absolute: only well-formed XML is minified — 0 bytes of output are produced for invalid input.
Frequently asked questions
Does minifying XML break it?
The output stays well-formed as long as the input is well-formed, because the minifier validates first. The thing to watch is whitespace that carries meaning: text containing real characters is preserved byte for byte, but whitespace-only text nodes between child elements are removed.
How much smaller will my file be?
Usually 10–40% for indented configuration files; flat files with long text values shrink much less. The tool reports the exact before/after byte counts and the percentage saved for your document.
Does the minifier remove comments?
No. Comments are preserved. Silently deleting them would change the document in ways a size counter cannot show, so removing comments is left to you.
Can I minify a 5 MB XML file?
No. Input is capped at 2 MB (2,097,152 bytes) to keep the browser responsive; larger files are refused with a message that states the size and the limit. Use xmllint --noblanks or a build plugin for large documents.
Is my XML uploaded when I minify it?
No. Minification runs locally in your browser and makes no network request with the document. Nothing is stored.
Can I format the minified result again?
Yes. Paste the minified output back into this page or into the XML Formatter page and it will be re-indented. The round trip is content-preserving, so the text values are unchanged.