XML Minifier

XML is verbose twice over: tags repeat, and pretty-printed files spend a lot of bytes on indentation. For a document that a parser will read anyway, that indentation is pure overhead — in deep documents it can be a third of the file. Minification removes it without touching the information the document carries.

This minifier is the same engine as the XML Formatter, run in reverse. Because the document is parsed into a tree before it is compacted, the output stays well-formed: tags remain balanced, attribute values keep their quotes and every entity reference survives.

How to minify XML

1. 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.

2. 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.

3. Check the size change

   The status line shows input bytes, output bytes and the percentage saved. Size is measured in UTF-8 bytes, not characters, so non-ASCII content is counted correctly.

4. Copy the result

   Copy result puts the compact XML on your clipboard. If you need to read it again later, paste it back here or into the formatter and it will be re-indented.

What minification removes and what it keeps

Keeping comments is a deliberate choice. Many minifiers strip them, which is fine for build artifacts but risky for hand-edited files: a comment may hold a TODO list, a license header or a note about why an element exists. This tool removes bytes, not decisions. If comments should go, delete them deliberately before minifying.

How much smaller does XML get?

The saving depends on nesting depth, indentation width and how much text the document contains. A configuration file with 4-space indentation and elements nested six levels deep loses a lot of whitespace; a flat document with two levels and long text values loses almost nothing. In practice 10–40% is a normal range for indented configuration and generated data, and the before/after counter reports the real number for your specific file instead of an estimate.

Two examples make the range concrete. A 120 KB Spring configuration with four-space indentation typically drops to roughly 80 KB. A flat 2 KB API response whose elements carry long string values may drop by only a few percent. Both results are correct: the tool reports what happened rather than promising a ratio.

Does minifying XML break anything?

Minification changes text nodes, and that sentence deserves attention. Whitespace-only text nodes between child elements are removed on purpose. If a consumer treats that whitespace as content, the output will behave differently. The classic example is XHTML: <b>a</b> <b>b</b> has a significant space between the two elements, and it is preserved here because it sits in mixed content. An element such as <block> <line/> </block>, where the whitespace around the child is insignificant, is compacted.

Any text value containing a non-whitespace character is copied byte for byte, including leading and trailing spaces around that character. A newline inside a <message> element survives; the newline just before the closing tag does not, because it is whitespace-only and belongs to element-only content.

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, so you can compare before and after without guessing.

Minify vs gzip: which should you use?

They solve different problems and combine well. Minification removes bytes from the document itself, so the saving survives storage, copy-paste, parsing and embedding. gzip or Brotli compress the byte stream and usually shrink a file by 80–95%. If the XML travels over HTTPS and the server already compresses responses, gzip captures most of the redundancy — but minification still helps with memory use, log volume and files bundled inside an application.

For most web payloads the practical advice is simple: minify what you ship, then let the transport compress it. For a configuration file consumed on a device or embedded in firmware, minification alone is the win.

When should you minify XML?

• Build artifacts: minify generated XML before packaging so installers and app bundles carry fewer bytes.
• Embedded documents: Android layouts, SVG and similar XML-derived formats are parsed at runtime, not read by humans, so indentation buys nothing.
• Log and telemetry payloads: smaller batches cost less to transmit and store.
• Size-limited environments: firmware, embedded devices and message queues with hard payload limits.
• Not for pull requests. Hand-edited configuration should stay formatted — reviewability matters more than bytes in a repository.

Limits and privacy

Everything happens in your browser; the document is never uploaded. As with the formatter and validator, input is capped at 2 MB (2,097,152 bytes) so a large paste cannot exhaust the tab’s memory. Oversized input is refused with its size and the limit. For larger files, xmllint --noblanks or a build plugin is the right tool.

Minification runs only on well-formed XML. That ordering matters: removing whitespace from a document with unbalanced tags would produce output that is smaller and wrong, so the tool validates first and refuses to emit anything when the input is broken.

Frequently asked questions

Related XML tools