What it does
Three operations, in order: remove HTML comments, collapse runs of whitespace to a single space, and remove whitespace between adjacent tags. Everything else is left alone.
What it protects
<pre>and<textarea>— whitespace is visible content<script>and<style>— a different language, with its own rules<!--[if ...]>— conditional comments are directives, not commentary
Where the saving is real
For a page served with gzip or brotli, expect a small single-digit percentage after compression. The cases worth doing it for are the ones without compression:
- HTML email, where clients often receive the raw payload
- An inline SVG or template literal embedded in JavaScript
- Markup stored in a database column or a JSON field
- Anything with a hard size limit
For everything else, put it in the build and keep the source readable.
Questions
Is minified HTML worth it when gzip exists?+
Marginally, for most sites. Compression already handles repeated whitespace well, so the extra saving is usually a few percent. It matters where compression is absent or the payload is small: an email template, an inline SVG, a snippet embedded in JSON.
What is not removed?+
Anything inside pre, textarea, script and style, and conditional comments. The first two because whitespace there is visible content, the last two because they hold another language, and conditional comments because they are instructions rather than notes.
Could this break my page?+
Collapsing whitespace between inline elements can remove a rendered space. This minifier collapses runs of whitespace to a single space rather than deleting them between text, which preserves the visible gap — but check a page with a tight inline layout before shipping.
Should I minify by hand?+
No. This is for one-off snippets and for seeing what the difference actually is. In a real project the build step should do it, so the source in your repository stays readable.