XML Minifier

Q: Does minifying change what my document means?

It should not, and that is the design constraint. Only whitespace between elements is removed — the part that exists for human readability and that a parser discards anyway. Everything else is left exactly as written: comments, CDATA sections, the XML declaration, attribute order and spacing, and self-closing tag style. If you compare the parsed result of the input and the output they are identical, which is the only definition of correctness that matters here.

Q: Why is whitespace inside an element sometimes kept?

Because whitespace inside an element that holds text is part of that text. In an element like a title or a description, the spaces between words are content and removing them changes the value. What gets removed is the whitespace between elements — the newlines and indentation that separate one tag from the next and carry no meaning. Runs of whitespace inside text are collapsed to a single space, which is safe for the overwhelming majority of documents but can be turned off if yours treats them as significant.

Q: Why not just parse the document and write it back out compactly?

Because that is what a formatter does, and it destroys things a minifier has no right to touch. Parsing and re-emitting loses comments, normalises CDATA into ordinary text, rewrites attribute order and quoting, and may change a self-closing tag into an open-and-close pair. Every one of those is a change beyond whitespace. This tool scans the source instead, tracking whether it is inside a tag, a comment or a CDATA section, and removes only what it is safe to remove.

Q: Should I remove comments?

It depends entirely on what they are. Genuine notes to future maintainers are dead weight in a transmitted document and worth removing. But some systems use comments as functional markers — server-side includes, templating directives, and certain build pipelines all put instructions in comments — and stripping those breaks the document in ways that are hard to trace. The option is off by default for that reason: removing them should be a decision, not something that happens to you.

Q: How much smaller will my XML get?

Usually 15 to 40 percent for a document that was indented for reading, and close to nothing for one that was machine-generated on a single line. Deeply nested documents gain the most, because every level adds indentation to every line. As with any minification, keep it in proportion: gzip and brotli already collapse repeated whitespace very effectively, so the saving on a compressed response is considerably smaller than the raw figure.

Q: What if my XML is not well formed?

The tool checks first and tells you, including the line, because minifying a broken document produces a smaller broken document and hides the original problem. It also flags unescaped ampersands specifically — the most common XML error by a wide margin, and one that many parsers tolerate silently. If you see that warning, fix the source rather than shipping the minified version; a strict parser downstream will reject it either way.

Strip indentation from XML without touching comments, CDATA, attributes or anything else that carries meaning.

XML

Collapse whitespace inside text Remove comments

Minified

Minification only changes whitespace. Comments, CDATA, attributes and tag style are all preserved, so the parsed result is identical to your input.

What It Does

Removes the indentation and line breaks that make XML readable to people and mean nothing to a parser, and changes nothing else. That last part is the whole design. It would be far easier to parse the document and write it back out compactly, but doing so quietly destroys comments, flattens CDATA sections into ordinary text, reorders attributes and rewrites self-closing tags — all changes well beyond whitespace, and all things a minifier has no business doing. This scans the source instead, tracking whether it is inside a tag, a comment or a CDATA block, and removes only what is genuinely insignificant. It also checks the document is well formed before it starts, since minifying broken XML just gives you smaller broken XML.

When to Use It

An XML payload is being transmitted frequently and the indentation is pure overhead on every request.
A configuration document is embedded inside another format and its whitespace is inflating the container.
You are storing XML in a database column and want it compact without losing anything.
A SOAP envelope needs to go into a test fixture as a single line.
You want to see how much of a document's size is indentation before deciding whether minifying is worth automating.

Worked Examples

<catalog>
    <book id="1">
        <title>XML Basics</title>
    </book>
</catalog>

The straightforward case. All the indentation goes, the id attribute and its quoting survive untouched, and the parsed result is identical to the original.

<a>
  <!-- keep this -->
  <b><![CDATA[  spaced   content  ]]></b>
</a>

The two things a naive minifier destroys. The comment survives because comments are preserved by default, and the CDATA content keeps its internal spacing exactly, because CDATA is verbatim by definition.

<note>
  <body>Some text with    inner spacing</body>
</note>

Text content versus structure. The indentation around the elements disappears, but the words inside the body stay — with their internal run collapsed to a single space, which is what a browser or parser would render anyway.

Features

Only insignificant whitespace removed

Comments preserved by default with an option to strip

CDATA sections kept verbatim

XML declaration and DOCTYPE preserved

Attribute order

spacing and quoting untouched

Self-closing tags left as written

Well-formedness checked before minifying

Unescaped ampersands flagged specifically

Byte count before and after with the percentage saved

Runs entirely in your browser

How to Use

1. Paste your XML or import a file. 2. The minified version appears immediately with the saving shown. 3. Check any warning about well-formedness before using the output. 4. Turn on comment removal only if you are sure none of them are functional. 5. Copy the result.

Common Mistakes

Minifying by parsing and re-emitting. It loses comments, normalises CDATA and rewrites attributes — every one of those is a change a minifier should never make.
Stripping all whitespace including inside elements. Spaces between words in a text node are content, and removing them changes the value.
Removing comments without checking what they are. Some systems put functional directives in comments, and stripping those breaks the document silently.
Minifying a document that is not well formed. You get a smaller broken document and lose the formatting that would have helped you find the problem.
Expecting the raw saving on the wire. Gzip and brotli already handle repeated whitespace well, so the gain on a compressed response is much smaller than the figure here.

Frequently Asked Questions

Does minifying change what my document means?

Why is whitespace inside an element sometimes kept?

Why not just parse the document and write it back out compactly?

Should I remove comments?

How much smaller will my XML get?

What if my XML is not well formed?