html-minifier 4.0.0 in your browser — strip comments, collapse whitespace
Quick answer: HTML minification removes comments and collapses runs of whitespace to single spaces (never inside <pre>, <textarea>, <script>, or <style>). Percent saved = (input − output) ÷ input × 100. On our 1,011-byte sample page, the conservative pass outputs 773 B (23.5% saved) and the aggressive pass 742 B (26.6%); all 40 tags and the doctype survive, and the only thing deleted outright is the comment. Runs locally — markup never uploads.
| Preset | What it does | 1,011-B sample → | Saved |
|---|---|---|---|
| Conservative | Removes comments, collapses whitespace between tags | 773 B | 238 B (23.5%) |
| Aggressive | …plus unquotes attribute values, drops spec-redundant attributes | 742 B | 269 B (26.6%) |
| Aggressive, gzipped | Transport compression on top | 454 B | vs 472 B conservative |
Measured with html-minifier 4.0.0 — the exact vendored build this page loads — on the sample behind the Sample button. Deeply indented templates shrink further; already-compact server output shrinks less. Integrity check: the sample's 41 raw "<" characters are 40 tags + doctype plus one comment — after either pass exactly 40 remain, so nothing but the comment was deleted.
The engine is html-minifier 4.0.0 (MIT), the classic kangax minifier, vendored on this site as a self-contained browser bundle and run locally in your tab. It parses markup with a real HTML tokenizer rather than regexes, which is how it knows that whitespace inside <pre> and <script> is load-bearing and must stay.
Bytes saved = input − output; percent = (input − output) ÷ input × 100. UTF-8 bytes, and gzip columns when your browser supports CompressionStream. HTML compresses well over the wire (523 → 454 B on the sample), so the raw and gzip columns bracket the true win.
Paste markup (or load the Sample), pick a preset, and output updates as you type. Conservative is the right default for production pages: comments gone, whitespace collapsed, every attribute still quoted. Aggressive also unquotes attribute values and removes attributes the spec defines as defaults — a few percent more, at the cost of hand-editability. Malformed markup gets html-minifier's own parse error with a position hint.
The Sample button loads a 1,011-byte store page: head with meta and a stylesheet link, a nav, a product card, a footer. The conservative pass returns 773 bytes — the <!-- Demo store product page --> comment is the only content that disappears; every one of the 40 tags and the doctype is still there, and the paragraph text collapses to single spaces without merging words. The aggressive pass reaches 742 bytes mostly by unquoting (class=product-card, lang=en). Gzipped, 523 bytes in becomes 454 out. Inline <script> and <style> contents are left byte-for-byte intact by both presets — minify those with the JS and CSS siblings first, then wrap the minified HTML around them.
Almost always. HTML treats any run of whitespace as a single space between inline elements, so deleting indentation and newlines renders identically — except inside <pre>, <textarea>, and <script> and <style> blocks, where whitespace is significant. html-minifier knows this and leaves those elements alone by default. The one visual risk is between inline elements where your CSS relies on the whitespace character for a gap; if a layout was silently using that 4px space, replace it with a margin before minifying.
Typical hand-written or framework-rendered markup loses 15-30%: our 1,011-byte sample page drops to 773 bytes conservatively (23.5%) and 742 bytes aggressively (26.6%). Template-heavy markup with deep indentation shrinks more; server-rendered output that's already compact shrinks less. After gzip the three sizes sit within about 70 bytes of each other — minify HTML for parser and cache wins more than network ones.
Attribute quotes where the spec allows unquoted values (class=x instead of class="x"), redundant attributes the HTML spec marks as defaults (type="text" on inputs, for example), and type attributes on script and link tags whose values are their defaults. Those are spec-safe, but they make the file harder to hand-edit and some validators and templating tools expect the quotes — which is why they're not in the default preset.
No — by default this tool leaves the contents of script and style elements untouched; it only removes the whitespace around the markup. html-minifier can also minify their contents, and the vendored build includes working JS minification, but enabling content minification changes behavior inside those blocks, so this page keeps it off. Use the dedicated tools for that: minify your JS and CSS first, then minify the HTML around them.
removeComments deletes standard <!-- --> comments in both presets. Conditional comments targeting old Internet Explorer (<!--[if lt IE 9]>) are structurally comments too — if you still serve legacy bundles through them, test after minifying, because anything comment-based will be treated as a comment. Server-side includes and comment-based placeholders (<!-- more -->) also disappear, so don't minify templates that carry them.
No. The html-minifier 4.0.0 engine is vendored on this site and runs in your browser; nothing is sent to a server. That said, if your HTML embeds secrets — API keys in templates, internal URLs — follow your employer's policy on pasting into third-party pages.