Whitespace collapsing
Runs of spaces, tabs, and newlines between tags are reduced to a single space (or removed entirely where safe), which dramatically reduces file size without changing rendered output.
HTML Minifier removes comments and collapses unnecessary whitespace from HTML markup, producing a smaller payload that browsers can download and parse faster without changing how the page renders.
HTML Minifier is a free, browser-based tool that compresses HTML documents and fragments by stripping comments, collapsing runs of whitespace between tags, and removing redundant spaces inside opening tags. The output is functionally identical to the input — every browser will render the minified version exactly the same way — but the byte count is meaningfully smaller, which translates to faster downloads, faster parsing, and less mobile data usage.
HTML Minifier is safe by default: content inside <pre> and <textarea> is preserved exactly because its whitespace is rendered to the user, and <script> and <style> sections are kept intact so embedded code is not silently broken. You can toggle comment removal off if you rely on conditional comments or templating engine markers, and you can toggle whitespace collapsing off if you only want to remove comments.
Typical users are developers preparing email templates for transactional sending where every kilobyte costs, frontend engineers shaving bytes off above-the-fold HTML to improve Largest Contentful Paint scores, and authors of static documents who want a smaller artifact to commit to a repo. Because all processing happens locally, your templates and customer-facing markup never leave the device.
Runs of spaces, tabs, and newlines between tags are reduced to a single space (or removed entirely where safe), which dramatically reduces file size without changing rendered output.
HTML comments are stripped from the output by default. A toggle lets you keep them when your templating engine, build tool, or email client relies on conditional or marker comments.
Content inside <pre> and <textarea> is left untouched because that whitespace is visible to the user. HTML Minifier never silently changes how text appears on screen.
Script and style sections are preserved so embedded JavaScript and CSS continue to behave correctly. If you need to compress those too, run them through the dedicated JS and CSS minifiers first.
After each run, the tool displays the input size, output size, and percentage saved. This makes it easy to confirm that minification actually helps for your specific markup.
Everything happens in your browser. The HTML you paste is never transmitted, so prelaunch templates and customer data remain on your device.
Browsers ignore most whitespace between tags. A line break between </p> and <p> renders the same as no line break at all, which means those bytes are pure overhead in the HTTP response. HTML Minifier collapses those runs of whitespace down to the minimum that still preserves visible spaces between inline elements, recovering bytes that would otherwise be wasted on the wire.
Inline whitespace inside text content is treated more carefully. Browsers do render the space between two words inside a paragraph, so HTML Minifier preserves at least one space when collapsing inside a text node. This is the difference between a correct minifier and a naive regex strip — the latter can accidentally fuse words together and break the rendered text.
Comments are a different category. HTML comments add no rendered output, but they can be load-bearing for templating engines, email clients, and conditional rendering hacks. HTML Minifier removes them by default because most production HTML does not need them, but exposes a toggle so the rare case where they matter is supported without surgery on the output.
Input
<div>
<h1>Hi</h1>
<!-- TODO: link -->
<p>Hello world</p>
</div>Output
<div><h1>Hi</h1><p>Hello world</p></div>HTML Minifier is great for one-off jobs, but production sites benefit from automated minification on every build. Use this tool to evaluate the savings, then move the same logic into your build step so every release benefits without manual effort.
Commit the beautified version of templates to version control so diffs are reviewable. Minify only as part of the build output, not in the source files developers edit.
Legacy Outlook and IE rendering hacks rely on HTML comments. If your output targets those environments, turn off comment removal so the conditional logic survives.
HTML Minifier deliberately leaves inline JS and CSS untouched. Run those through JavaScript Minifier and CSS Minifier first if you need full compression across the document.
Minification reduces the raw payload, but most savings come from also enabling gzip or brotli on the server. The two compress in different ways and combine well, so enabling both gives the smallest delivered size.
The source may already be minimal, or both toggles may be off. Make sure "Collapse whitespace" is on for the biggest savings.
Turn off "Remove comments" so HTML Minifier keeps comments needed for legacy Outlook or IE conditional rendering.
Gmail clips messages larger than 102KB. Minifying transactional templates often shaves enough bytes to keep the whole message visible without the "view entire message" link.
Developer comments slip into production responses more often than expected. HTML Minifier removes them in one pass, so internal notes never reach the public payload.
Inline critical CSS and the first viewport of HTML need to fit into the first packet for fast LCP. Minifying gets you closer to the budget without restructuring the page.
CMS editors emit unpredictable whitespace. Running the output through HTML Minifier normalises the spacing so the response is consistent across edits.
Static site generators produce indented HTML by default. Minifying the export shrinks the bundle without changing any application code.
Yes. HTML Minifier only removes whitespace and comments that the browser ignores when rendering. Content inside <pre> and <textarea> is preserved, and inline text always keeps at least one space between words. The output renders the same on every standards-compliant browser.
No. Embedded <script> and <style> blocks are passed through unchanged so the code inside continues to behave correctly. If you also want to compress JS and CSS, run them through the dedicated JavaScript Minifier and CSS Minifier tools first.
Keep comments if your output targets legacy Outlook or IE through conditional comments, or if your build pipeline uses HTML comments as templating markers. For most production HTML, removing comments is safe and saves bytes.
It depends on the source. Heavily indented and commented HTML can shrink by 20–40 percent, while already-compact HTML may only shrink by a few percent. The tool reports the exact byte savings after each run.
Yes, with two caveats. Make sure your tests cover the minified output so any subtle whitespace dependency is caught early, and disable comment removal if you rely on conditional comments. Otherwise the minified output is a drop-in replacement for the source.
No. Minification runs entirely in your browser. Your HTML, including any internal product names or unreleased designs, is never uploaded as part of the operation.
Yes, by running the output through HTML Beautifier on the same site. Round-tripping through both tools is safe as long as the input is valid HTML to start with.
Yes. Gzip and brotli compress repetitive text very well, but minification removes the bytes that gzip would otherwise have to compress. The two techniques stack, and minifying before compression typically produces the smallest delivered payload.
HTML Minifier shrinks markup without touching how it renders — use it to fit transactional emails under client thresholds, improve Core Web Vitals, and ship leaner pages from your existing templates.