Free online tool
HTML Minifier
Paste HTML to collapse whitespace and remove comments. Runs 100% in your browser.
Minified HTML will appear here…
Why minify HTML?
HTML minification removes indentation, line breaks, and non-conditional comments so the browser downloads and parses fewer bytes. On content-heavy pages the win can be significant: a 120 KB HTML page routinely compresses to 80–90 KB before gzip even runs, and gzip then compresses the tighter file even further. Fewer bytes means a faster first paint, better Core Web Vitals scores, and a smoother experience on flaky mobile connections.
Safe defaults
The tool preserves conditional comments used by older Internet Explorer versions (they start with <!--[if), keeps single spaces inside text nodes so words don't run together, and never touches attribute values. That means it's safe to run on production HTML including landing pages, transactional email templates, and static export output from static-site generators.
Best paired with
Pair HTML minification with gzip or Brotli compression at the server level, plus a CSS and JavaScript minifier. Individually each step saves a few kilobytes; together they can cut your total transfer size in half. If you host on a modern platform like Vercel, gzip and Brotli happen automatically — this tool covers the HTML piece that platforms sometimes miss.
+Will it break my <pre> blocks?
Whitespace inside <pre> tags is technically significant. For pages with lots of code samples, review the output before shipping.
+Is it safe on templates with server tags?
Yes, as long as the template tags do not rely on line breaks between them. Test one file first if you use unusual syntax.
+Does it change semantic HTML?
No. Tags, attributes, and text content are preserved. Only whitespace and standard comments are removed.
Trimming markup while keeping the DOM identical
HTML minification removes bytes that browsers ignore anyway — comments, redundant whitespace between block-level tags, and optional closing tags in some cases — without altering the parsed document structure that JavaScript and CSS actually interact with.
It's a smaller win than CSS or JS minification on most modern sites, since HTML payloads tend to be lighter than script bundles, but on server-rendered pages with deeply nested templates and generous indentation, it still meaningfully shrinks what has to be parsed before the first paint happens. Treat it as a final packaging step applied to generated output, not to hand-authored source templates you still need to edit and read later.
Whitespace is not always safe to touch
Collapsing whitespace inside a <pre> block or a <textarea> changes what the user actually sees, since those elements preserve whitespace by specification rather than collapsing it the way normal flow content does. A naive minifier that blindly strips all whitespace everywhere can quietly break code samples, ASCII art, or form defaults, so a correct implementation has to be aware of which elements are whitespace-sensitive before touching their contents.
Attribute quoting and boolean attributes
Some minifiers remove quotes around attribute values with no special characters and drop the value entirely from boolean attributes like disabled="disabled", writing just disabled instead, since HTML parsers treat the attribute's mere presence as true regardless of its value. This is spec-compliant but occasionally trips up strict XML-based tooling or templating systems downstream that expect well-formed attribute syntax.
Why this still matters in an SPA-heavy world
Even with client-rendered apps handling most of the page, the initial HTML shell affects time-to-first-byte and first paint, and every comment or stray whitespace node in a server-rendered template adds parse time on constrained mobile connections. Run this on the final template output, not on source files with build-time comments and template syntax still embedded, or you risk stripping markers your templating engine needs.
Optional tags and the risk of over-aggressive removal
The HTML spec technically permits omitting certain closing tags, like </li> or </p>, in specific contexts where the next tag implies closure, and some minifiers exploit this to save bytes. This is valid per spec, but it can confuse other tools in the pipeline, like static analyzers or accessibility checkers, that expect explicit tag pairs, so it's worth testing that downstream tooling still behaves correctly after this kind of aggressive minification is enabled. Inline event handler attributes and inline scripts also deserve caution during minification, since a whitespace-collapsing pass that reaches inside a <script> block by mistake can mangle template literals or comments that were never meant to be treated as ordinary HTML text.
People also search for
- html minifier online
- minify html code
- compress html file
- remove html comments whitespace
- reduce html page size
- html whitespace collapse tool
- optimize html for production
- html minify vs beautify