What minifying HTML actually saves you
Minifying removes what the browser does not need: comments, indentation, line breaks and the gaps between tags. The page renders identically, but there are fewer bytes to send. On a heavily indented page the saving is often 10–25% before compression.
Be realistic about the gain, though. If your server already uses Gzip or Brotli — most do — compression has already collapsed most of that repeated whitespace. Minifying on top still helps, but the extra saving is usually small. The bigger wins on page weight are almost always images and JavaScript, not markup.
Some whitespace genuinely matters, so this tool leaves it alone: anything inside <pre> or <textarea> renders exactly as written, and JSON-LD structured data is left formatted so it stays valid. Conditional comments are kept too.
Minify at build or deploy time, not in your source files. You want to keep reading and editing the readable version.
Real numbers, and where the bigger wins are
Less than people expect, and more than nothing. Hand-written or template-generated HTML typically carries 10–25% of its weight in indentation, line breaks and comments. A 60 KB page might come down to around 48 KB. Gzip or Brotli, which your server almost certainly already applies, then compresses whichever version you send — and compression is very good at repeated whitespace, so the gain after compression is smaller again.
That is the honest picture: minifying HTML is a real but modest win, worth taking on pages you serve constantly, not worth agonising over. The larger savings on almost every site are in images and JavaScript, not markup.
What minifying should never touch
Whitespace is not always decoration. Inside <pre> and <textarea> it is content — collapse it and you change what the visitor sees. Code samples lose their indentation, and a textarea’s default value gains or loses line breaks.
A single space between inline elements can matter too. <span>one</span> <span>two</span> renders as “one two”; strip that space and you get “onetwo”. This tool preserves single spaces between tags for that reason, and leaves pre and textarea contents alone entirely.
Comments: which ones to keep
Most HTML comments are notes to yourself and can go. Two kinds should stay:
- Conditional comments such as
<!--[if IE]>, which are instructions to the browser rather than notes. Rare now, but fatal to remove where still in use. - Licence headers in third-party code. Removing them may breach the licence you are relying on.
Anything that is genuinely a note — section markers, reminders, commented-out blocks — is dead weight in a file you send to every visitor.
Minify at build time, not by hand
Pasting into a tool is right for a one-off: an email template, a landing page, a snippet you are about to embed. For a site you actively edit, minifying by hand is a trap — you end up maintaining an unreadable file, or maintaining two copies and forgetting which is current.
Keep your source readable and minify on the way out. On WordPress, LiteSpeed Cache, WP Rocket and similar plugins do this automatically on the rendered page. In a build pipeline, html-minifier-terser handles it. Use this tool for the one-off, not as a workflow.
Minify or compress?
They are different things and they stack. Minifying removes characters the parser does not need. Compression — gzip or Brotli — re-encodes what remains for transfer and is undone by the browser on arrival.
If you only do one, enable compression: it is a server setting, applies to everything, and saves far more. Minifying is the smaller extra gain on top. Checking that Brotli is on is a better use of ten minutes than minifying a hundred pages.