What minifying removes
HTML browsers treat any run of whitespace between tags as a single space, so the line breaks and indentation that make source readable add bytes without changing the page. Minifying removes HTML comments and collapses that inter-tag whitespace to produce a smaller, faster-loading document.
The minifier strips <!-- ... --> comments, collapses multiple spaces to one and removes whitespace directly between adjacent tags - all changes a browser cannot see in the rendered output.
Worked example
An indented block collapses to a single line:
<div> with comments, line breaks and four-space indents.<div class="box"><h1>Hello</h1><p>A short paragraph.</p></div>What it protects
Some whitespace is significant: text inside <pre> and <textarea> renders literally, and the code inside <script> and <style> can break if spacing changes. The minifier detects those regions and leaves them untouched, collapsing whitespace only where it is safe. Everything runs locally, so your markup never leaves the browser.
The one place HTML minification can change your layout
HTML minifying is usually invisible — but there's a real trap. In the default display:inline and inline-block world, the whitespace between elements is rendered as a literal space. Consider:
<a>One</a>\n<a>Two</a> renders as "One Two" with a visible gap.<a>One</a><a>Two</a> renders as "OneTwo".This is the classic "my inline-block buttons used to have gaps and now they're touching" bug. It's not a flaw in minifying — it reveals that your layout was relying on source whitespace. The robust fix is to control spacing in CSS (flexbox/grid gap, or margins) rather than depending on line breaks in the HTML. If you do rely on inline-block gaps, test the minified output before shipping.
When HTML minification is — and isn't — worth it
For static pages, minifying the HTML shaves real bytes off every request. But weigh it against where your weight actually is:
- Most HTML documents are small relative to images, fonts and JavaScript. Minifying a 12 KB page to 9 KB matters less than lazy-loading one hero image.
- Server compression already helps a lot. gzip/brotli compress repetitive markup well, so minify-then-compress yields a smaller additional gain than on a binary asset.
- Server-rendered pages from a framework (Next.js, Rails, Laravel) are best minified by the build step or a CDN feature, not pasted by hand each deploy — keep the source readable and automate the transform.
Where this tool shines: one-off static pages, email HTML (where every byte and every stray space can matter), embedding markup in a string, or simply checking how much dead whitespace a file carries. Keep an un-minified copy as your working source — minified HTML is painful to edit by hand.