Free HTML Minifier
Compress HTML code by removing comments, whitespace and simplifying attributes.
Why HTML Minification Still Matters in 2026
HTML is the first thing the browser downloads, parses and renders on every page load. The HTML document is on the critical rendering path: the browser cannot start fetching CSS, JS or images until it has parsed enough HTML to discover what they are. Every kilobyte of HTML transferred and parsed delays Time to First Byte (TTFB) and Largest Contentful Paint (LCP), two of the three Core Web Vitals Google uses as ranking signals. HTML minification removes the bytes humans put there for readability (whitespace between tags, comments, redundant attribute syntax) without changing what the browser sees. Gzip and Brotli compression at the CDN edge handle most of the size (repeated tag names compress beautifully) but minification on top still saves typically 5-15% additional bytes by removing what the compressor can't see (semantically dead bytes that compress to similar but not identical output). That sounds small until you multiply it by every page request to a high-traffic site; the bandwidth bill and the LCP improvement both matter at scale.
There are two complementary cases where the savings are larger: server-side rendered pages (Next.js, Remix, Hugo, Eleventy) where the HTML is generated fresh per request and the framework's templates often include generous indentation and helpful comments; and static-site builds where minification runs once at build time and pays off forever. Modern static-site generators ship HTML minification as a build-time option: Hugo's --minify flag landed in v0.47 (17 August 2018), Eleventy uses html-minifier-terser via plugin, Next.js applies it through SWC, and Astro 3.0 ships built-in HTML minification with the optional astro-compress integration layered on top. For hand-rolled HTML or templates without a build pipeline, this in-browser minifier is the path of least resistance.
What a Minifier Actually Does
- Inter-element whitespace collapse. Spaces and newlines between tags are stripped,
<p> Hello </p>becomes<p>Hello</p>when safe. The "when safe" qualifier matters: whitespace between inline elements (<span>,<a>,<em>) is rendered (so "foo bar" should preserve the space between the spans). Whitespace between block elements (<div>,<p>) usually isn't. - Comment removal.
<!-- ... -->blocks are stripped. Conditional comments (<!--[if IE]>...<![endif]-->) are preserved when present, even though Microsoft removed conditional comment processing from Internet Explorer 10 onward, they're safe to drop on any site that doesn't support IE9 or older. - Attribute simplification. Attribute quotes are removed when the value contains no whitespace, no
>, no=, and no quote characters of either kind:class="btn"becomesclass=btn. Boolean attributes are simplified:disabled="disabled",checked="checked",selected="selected",readonly="readonly"all become just the attribute name. Default attribute values are dropped:type="text"on an input,type="text/javascript"on a script tag,method="get"on a form. - Void elements stay void.
<br>,<hr>,<img>,<input>,<meta>and<link>have no closing tag in HTML5. The XHTML self-closing slash (<br />) gets dropped:<br />becomes<br>. - Protected content.
<pre>,<textarea>,<script>and<style>contents are preserved verbatim because their whitespace is significant. Inline JavaScript and CSS need their own minifier passes (separate tools).
The Whitespace-Significant Cases That Will Bite You
The biggest risk in HTML minification is collapsing whitespace where it matters. Inline elements with surrounding whitespace render the whitespace as a visible space; foo <em>bar</em> baz has spaces around bar; if a minifier collapses those spaces to nothing the rendered text becomes "foobarbaz" with no separation. Conservative minifiers preserve any single space between text and inline elements; aggressive ones (with conservativeCollapse: true off) remove it. Whitespace inside elements with white-space: pre CSS is also rendered; minifiers can't see CSS rules and may collapse it incorrectly. Comments removed inside conditional comments can break IE-specific behaviour on legacy sites. Comments used as build markers (Vue's <!---> placeholders, Angular's <!--bindings={...}-->) need to survive the minification pass. Modern minifiers handle these cases; a regex-only approach (this tool) is conservative, it preserves whitespace inside the protected blocks but doesn't have full inline-vs-block awareness. For production sites with lots of inline-element-heavy prose, test the minified output before deploying.
HTML5's Permissive Syntax, and Why XHTML Lost
HTML5's permissiveness is what makes minification possible at all. XHTML (the abandoned XML-syntax HTML variant) required strict syntax: every tag closed, every attribute quoted, every attribute spelled in lowercase. XHTML 2.0 was abandoned when its W3C charter expired on 2 July 2009; HTML5 became a W3C Recommendation on 28 October 2014. HTML5 deliberately allows multiple equivalent syntaxes, <br> and <br/> are both legal; type="text" on an input is the default and can be omitted; quotes around class=btn are optional when the value is simple. This permissiveness is exactly what minifiers exploit: every "optional" syntactic element is bytes the minifier can drop. The trade-off is that minified HTML is harder for humans to read (which is fine because nobody reads production HTML except via View Source).
A Short History of HTML Minification Tooling
Will Peavy's HTMLMinifier (the willpeavy.com tool, mid-2000s through ~2010) was the original and most-cited browser-based HTML minifier, a single-page tool that took pasted HTML and emitted a stripped version. kangax's html-minifier (Juriy "kangax" Zaytsev, announced 9 March 2010 on his Perfection Kills blog) was the first serious Node.js HTML minifier; for nearly a decade it was the canonical Node tool, used by webpack-html-plugin, Gulp pipelines and most static-site generators. Kangax's last release was v4.0.0 on 1 April 2019; the repository has been effectively unmaintained since 2021 but is not formally archived. html-minifier-terser (maintained by Daniel Ruf with contributions from kangax, Alex Lam and others) is the actively-maintained fork that picked up where kangax left off; it's what webpack-html-plugin defaults to today and what most build pipelines actually run. Wilson Lin's minify-html is a Rust-based minifier with substantially better performance for large HTML inputs. tdewolff/minify is the Go alternative used in Hugo and various Go-based static-site generators. swc and Lightning CSS have HTML support in their respective Rust toolchains, used by Next.js (which moved off Babel onto SWC starting with Next.js 12) and Parcel respectively. html-minifier-next (announced via GitHub issue #1165 on 10 July 2025) is the newer kangax-fork that some projects are migrating to.
Email HTML, A Different World
HTML email is its own minification minefield. Email clients have notoriously varied parsers, Outlook 2007-2019 uses Microsoft Word's HTML rendering (designed for word-processed documents, not the web), Gmail strips <style> tags above a certain size threshold, Apple Mail and Yahoo Mail follow web standards more closely. Web HTML minification rules don't all apply to email: removing inter-tag whitespace can break Outlook's layout; removing optional quotes can break some webmail parsers; removing the type="text/css" attribute on inline <style> tags can be silently dropped by Gmail. The "right" minification level for email is much more conservative than for web HTML, typically just comment and whitespace removal, leaving everything else alone. Email-specific tools like MJML and Foundation for Emails handle the email-HTML quirks at compile time; running a generic web HTML minifier on a Mailchimp template will likely break it in Outlook.
AMP HTML and the Validator-First Approach
Google's Accelerated Mobile Pages project (launched 7 October 2015) takes the opposite approach: instead of minifying after the fact, AMP defines a strict subset of HTML that's already small by construction. AMP requires a single inline <style amp-custom> block (75 KB max as of 13 March 2020, raised from 50 KB), forbids most JavaScript except amp-script, and uses a strict validator to enforce all the rules. The project was deprioritised in 2021-2022 as the AMP carousel ranking benefit was reduced, and many publishers have walked away from AMP in favour of regular minified+optimised HTML; it's still used by news publishers who depend on Google Discover traffic. The relevance to a generic HTML minifier is that AMP shows what an aggressively-byte-conscious HTML standard looks like: opinionated, validator-enforced, and small.
Honest Scope: What This Tool Does and Doesn't
This tool is a regex-based HTML minifier, roughly 30 lines of JavaScript. It tokenises <pre>, <textarea>, <script> and <style> contents into placeholders so subsequent transformations cannot corrupt them; strips <!-- ... --> comments (with a lookahead to preserve <!--[if conditional comments); collapses whitespace between tags; conservatively removes attribute quotes when values contain only safe characters ([a-zA-Z0-9_-]+); and simplifies a hard-coded list of fifteen boolean attributes. What this tool does not do, that production minifiers handle: it does not drop optional end tags (</li>, </td> in many contexts), that requires understanding HTML5's content model; it does not remove redundant attributes from default values (type="text" on inputs, type="text/javascript" on scripts) beyond the ones explicitly listed; it does not minify inline <style> or <script> contents (use the dedicated CSS Minifier and JS Minifier tools for those, then paste back); it does not sort attributes alphabetically (which can improve gzip compression slightly); it does not handle SVG-specific minification rules. For projects with a build pipeline, use html-minifier-terser, minify-html or swc; for one-off HTML, this tool removes the friction.
Privacy: Why Browser-Only Matters Here
Server-side HTML minifiers require uploading the source. For published web pages this is harmless (the HTML is already public). For internal admin tool templates, unreleased product pages, A/B-test variant HTML, or email templates with personalised content, server-side minification is a leak. This tool runs the entire transformation in your browser via JavaScript, nothing crosses the network. Verify in DevTools' Network tab while you click Minify, or take the page offline (airplane mode) after it loads and the tool still works.
Frequently Asked Questions
How much smaller will my HTML be?
For hand-formatted HTML with comments and indentation, expect 10-30% raw-byte reduction; SSR templates with generous whitespace and HTML comments can hit 30-50%. After Brotli compression at the CDN edge, the additional saving from minification is more modest (typically 5-15%) but it's not zero, and at scale it adds up. Production minifiers (html-minifier-terser, minify-html) achieve slightly better numbers because they understand HTML5's content model and can drop optional end tags.
Will minification break my HTML?
For HTML where whitespace between tags isn't structurally significant, no. The risk cases: prose paragraphs with inline elements where whitespace is rendered (collapsing the space between <em> tags can run words together); CSS rules with white-space: pre on elements other than <pre> (the minifier can't see CSS); IE conditional comments containing critical IE-specific styles; framework hydration markers (Vue, Angular, React server-rendered hints). Test the minified output before deploying, for ordinary modern HTML this is rarely an issue.
Does it minify inline CSS or JavaScript?
No. Inline <style> and <script> contents are preserved verbatim, the minifier doesn't try to interpret CSS or JS syntax. To minify inline assets, use the dedicated CSS Minifier and JavaScript Minifier tools on the <style> and <script> contents separately, then paste them back into the HTML. For automated pipelines, html-minifier-terser optionally calls clean-css and Terser on inline blocks (set the minifyCSS and minifyJS options).
Should I use this for email HTML?
Probably not. Email clients have notoriously varied parsers, Outlook 2007-2019 uses Microsoft Word's HTML rendering, Gmail strips <style> tags above a size threshold, various webmail clients drop attributes silently. Web HTML minification rules don't all apply to email. For email templates, use email-specific tools like MJML or Foundation for Emails that handle the email-HTML quirks at compile time. Running a generic web HTML minifier on a Mailchimp template will likely break it in Outlook.
Should I use this if I already have a build pipeline?
Probably not, your bundler is doing this for you. Hugo's --minify flag (since v0.47, August 2018), Eleventy's html-minifier-terser plugin, Next.js's SWC, Astro 3.0's built-in HTML minification, they all minify automatically. This tool is for the cases your build pipeline doesn't cover: hand-rolled HTML pages, WordPress page templates outside the theme, one-off snippets, or quick experiments where setting up a build pipeline would take longer than the snippet itself.
Is my HTML uploaded?
No. The minifier is JavaScript running in your browser. The HTML you paste never crosses the network, verify in DevTools' Network tab while you click Minify, or take the page offline after it loads and confirm the tool still works. Internal admin tool templates, unreleased product pages, A/B-test variants and email templates with personalised content stay on your device.