HTML Minifier

HTML whitespace is not always insignificant

Minifying HTML is riskier than minifying CSS or JavaScript, because whitespace in HTML sometimes renders. Between block-level elements it collapses to nothing visible and can be removed freely. Between inline elements it renders as a single space, so removing it joins words together: <span>one</span> <span>two</span> becomes onetwo if the space is stripped. This is the single most common way an aggressive minifier breaks a page.

Inside <pre> and <textarea>, and anywhere white-space: pre applies, every character is literal. Touching that whitespace changes what the user sees. A safe minifier must know about these elements and leave their contents completely alone.

What is safe to remove

Comments, except conditional comments if you still support very old Internet Explorer. Leading and trailing whitespace inside block elements. Redundant closing tags that HTML5 makes optional, though removing them hurts readability for little gain. Quotes around attribute values that contain no spaces or special characters, which saves very few bytes and is rarely worth the reduced clarity.

Compression does most of the work

As with CSS, gzip and Brotli already handle repetitive markup extremely well. HTML is highly repetitive, so it compresses exceptionally efficiently: a document can commonly shrink by 75 to 85 percent through compression alone. Minifying before compression adds a comparatively modest further saving. Verify compression is enabled before spending effort on minification.

Server-rendered pages

For pages generated by a template engine, minifying the output on every request costs CPU on every request. It is usually better to keep templates tidy, enable compression, and skip HTML minification entirely. Minification makes most sense for static files produced once at build time.

Local processing

Everything runs in your browser, so pages containing customer data, internal endpoints or unreleased copy are never transmitted.