HTML Minifier

Minification is the last step before HTML meets the network: same document, fewer bytes. It sits at the end of a build for the same reason compilation does — the human-readable source is for people, and the shippable artefact is for machines.

What is removed

Whitespace between tags is the main target: the indentation, the newlines between elements and the runs of spaces that make source readable. HTML comments are dropped too, since they are never rendered. None of this changes what the browser paints, because the rendering engine already collapses inter-element whitespace to a single space.

What must be kept

Whitespace is content in a few places, and removing it there is a real bug:

• inside pre, where every space and newline is displayed literally;
• inside textarea, whose value is its raw text;
• in any element styled with white-space set to pre, pre-wrap or break-spaces;
• the single space between inline words, which must not be collapsed to nothing.

A minifier that does not understand these contexts will quietly reflow code samples and preformatted blocks. This one leaves them intact.

The compression caveat

If your HTML travels over HTTPS with gzip or Brotli enabled — and it almost certainly does — minification saves less than the raw byte count suggests. Indentation is repetitive, and repetition is exactly what those algorithms compress best. The two together usually beat either alone, but the marginal gain from minifying on top of compression is smaller than the character count implies.

It still matters when the markup is stored uncompressed, embedded in a length-limited field, served over a protocol that cannot compress, or delivered at a volume where a few percent of bandwidth is worth capturing.

Minify at build time, not by hand

The right place for this is a build step that reads your formatted source and writes a compressed artefact. Doing it by hand in an editor means the next person cannot read the file they have to maintain. Keep source pretty, ship it small.