Minifying HTML Without Breaking It

HTML is the format where minification gets philosophical, because some of its whitespace is invisible to the browser and some of it is the text. A safe HTML minifier is therefore less a delete-everything pass than a classifier: it must decide, byte by byte, whether a space is layout or content.

Two deletions and one protected list

By default the minifier does two things. It removes comments (<!-- like this -->), and it collapses runs of whitespace — spaces, tabs, newlines — down to a single space, then strips the whitespace that sits directly against a closing angle bracket, where tags absorb it anyway. Both steps are optional toggles. Around them sits one guard rail: the contents of <pre>, <textarea>, <script>, and <style> are lifted out before any whitespace is touched and put back verbatim, because in those four elements whitespace is content or code, not layout.

A worked example, with the space that survived

Take a 97-character document — a comment, an indented article with a heading, a <pre> block, and a paragraph. The minified output is 72 characters, a 26% saving:

<article><h1>Hello</h1><pre> keep this </pre> <p>World</p></article>

Three details repay attention. The comment is gone. Inside <pre>, the spacing survived character for character. And one space remains after </pre> — a collapsed remnant of the newline and indentation that used to sit there. It survives because it does not touch a >: the protected pre block broke the adjacency, and the minifier leaves a single space wherever none of its deletion rules apply. That is conservative behavior working as designed.

Collapsing, not deleting

Whitespace between tags renders invisibly, but a single space between two inline elements is a word separator: <a>one</a> <a>two</a> reads "one two", while gluing it into <a>one</a><a>two</a> reads "onetwo". This is why the minifier collapses runs to one space instead of deleting whitespace outright — the browser ignores extra spaces anyway, so collapsing changes nothing visually while keeping inline text readable. The bytes that vanish are the newlines and indentation a formatter added; the bytes that stay are the ones a reader would miss.

Why the four regions are untouchable

<pre> and <textarea> display and hold whitespace literally — collapse either and code samples or form defaults visibly change. <script> and <style> contain other languages, where a space can live inside a string or separate two tokens; rewriting them with HTML rules is how pages break. The right move is to pass those regions through and minify each with its own tool, as Why Code Is Minified (and When Not To) explains — every language loses its bytes differently.

HTML minifier or CSS minifier?

They differ at the core, not the surface. The CSS minifier's whole problem is mechanical — CSS is grammar, so removable space is found by punctuation rules, as What a CSS Minifier Actually Deletes shows. The HTML minifier's whole problem is classification: every byte is grammar, visible text, or protected content, and mistaking one for another breaks pages, which is why its design is organized around preserving regions rather than maximizing deletion. Attribute values are another hard line: the space inside alt="a red bike" is text, and no safe minifier touches it.

Try it yourself

Paste a small page — ideally one with a comment, some indentation, and a <pre> block — into the HTML Minifier and hunt for the spaces that survived; they mark exactly where content begins. Compare with the CSS Minifier, where nothing survives because nothing is content, and toggle the comment option to see how much of your file was notes to yourself.