Upload an HTML file and minify it to reduce file size for faster delivery while keeping the same HTML output.
.html file onto the editor. Snippets, full documents with <head> and <body>, and email templates all work — processing runs in your browser, so the source never leaves your machine.type="text" on <input>), remove optional closing tags (</li>, </p>, </body>), and minify embedded CSS and JavaScript. Each option is independent so you can pick a safe-and-conservative profile or go aggressive..html file. Output is ready for production deploy, CDN upload, or embedding in your build pipeline.HTML minification strips characters that the browser does not need to render the page — indentation whitespace, line breaks, HTML comments, default attribute values, and (optionally) closing tags that the HTML5 spec marks as omissible. Unlike CSS or JS minification, HTML minifiers have to be conservative: whitespace between inline elements like <a> or <span> is visually significant, and content inside <pre>, <textarea>, and <code> must be preserved byte-for-byte. Typical savings land in the 5-20% range on the raw HTML; layered on top of gzip or Brotli, you usually see another 5-10% over the compressed size because minification removes patterns the compressor would otherwise have to encode.
index.html of an SPA is the first byte the browser downloads. Trimming a few hundred bytes off the shell lowers TTFB and starts JS parsing sooner, which compounds on slow mobile connections.| Option | Typical savings | Risk of breakage |
|---|---|---|
| Collapse whitespace | 5-15% | Low — whitespace inside <pre>/<textarea>/<code> is preserved; collapses to one space between inline elements |
| Remove comments | 1-5% | Low — but breaks conditional comments (<!--[if IE]>) and build markers if not allow-listed |
| Remove redundant attributes | <1% | Very low — strips defaults like type="text", method="get" |
| Remove optional tags | 1-3% | Medium — </li>, </p>, </body>, </html> are valid to omit per HTML5 spec, but can confuse XML tooling and downstream parsers |
| Remove attribute quotes | <1% | Medium — only safe when attribute values contain no spaces, quotes, =, or > |
Minify inline CSS (<style>) |
2-10% | Low if the embedded CSS is well-formed |
Minify inline JS (<script>) |
5-30% on script-heavy pages | Medium — depends on the JS engine; ES6+ requires a Terser- or SWC-class minifier |
| Collapse boolean attributes | <1% | Low — disabled="disabled" becomes disabled |
| Use short doctype | One-time ~80 bytes | None — <!DOCTYPE html> is universal |
| Tool | Status | JS engine | Notes |
|---|---|---|---|
| html-minifier-terser | Last release v7.2.0 (Apr 2023); maintained but stale | Terser | The de-facto Node library since the original html-minifier (kangax) stopped updating |
| html-minifier-next | Active fork started 2025 | Terser or SWC (configurable) | Adds optional SWC engine for inline <script> minification — 4-7x faster than Terser on JS-heavy pages |
| @swc/html | Active (Rust-based) | SWC | Significantly faster than terser-based options for SSG pipelines; more conservative whitespace handling |
| Prettier | Active | n/a | Prettier is a formatter, not a minifier — no "minify mode"; pair with a real minifier in your build |
| XConvert HTML Minifier | This page | Browser-native | Client-side only; no upload of source HTML to a server |
Indentation whitespace, line breaks between tags, HTML comments, default attribute values (type="text", method="get"), redundant boolean attribute values (disabled="disabled" → disabled), and — if enabled — optional closing tags that HTML5 allows to be omitted. The DOM is unchanged; only the textual representation shrinks.
Rarely, but the failure modes are predictable. Collapsing whitespace between inline elements creates visible layout differences if it removes a space; conservative minifiers keep one space between inline tags. Whitespace inside <pre>, <textarea>, and <code> must be preserved — any reputable minifier does this automatically. The riskiest option is "remove optional closing tags" — valid per spec but can confuse downstream XML tooling and developers reading the source. Always render the minified output in a browser before deploying.
Yes. Gzip and Brotli compress repeated byte patterns, so they recover much of what minification removes — but not all. On real-world pages you generally see an additional 5-10% reduction in compressed size from minification because patterns like long comment blocks or deeply indented whitespace are noisy enough that compressors can't fully eliminate them. The wins are smaller than on uncompressed HTML, but they're free and they layer with compression.
When you have HTML that doesn't pass through a bundler. Common cases: hand-edited marketing landing pages, legacy CMS templates copy-pasted from a designer, email templates exported from MJML or Foundation, embeddable widget snippets, AMP page boilerplate, and static help-center pages. Anything that lives in a single .html file you edit by hand benefits from a one-off minify pass.
Enabling "Minify inline CSS" runs the contents of <style> blocks through a CSS minifier (same engine as the CSS Minifier). "Minify inline JavaScript" runs <script> block contents through a JS minifier (same engine as the JS Minifier). The style attribute and event handler attributes (onclick, onsubmit) are usually left untouched to avoid edge-case breakage — modern minifiers like SWC explicitly opt out of inline event-handler minification because constructs like bare return false parse differently.
{{ variable }} or <% %>?Most minifiers treat unrecognized syntax as text content and pass it through, so basic Handlebars / Mustache / EJS / Jinja templates usually survive. The risk is when template tags wrap around HTML structure (e.g. {% if %}<div>{% endif %} spanning a tag boundary) — the parser sees a malformed DOM and may rearrange things. Safer pattern: minify the rendered output, not the template source. If you must minify templates, use ignoreCustomFragments (in html-minifier-terser) to allow-list your template delimiters.
AMP HTML is a restricted subset of HTML with mandatory boilerplate. The <style amp-boilerplate> block must remain byte-for-byte identical to validate — minifiers must not touch it. The AMP project's allowed mutations are limited to inserting arbitrary whitespace immediately after the boilerplate <style> opens and before it closes, plus replacing single spaces with arbitrary whitespace in the boilerplate CSS. Use a minifier that explicitly recognizes the AMP boilerplate (or wrap it in an ignore-fragment) — otherwise an aggressive whitespace collapse will fail AMP validation.
The minifier processes documents up to several megabytes comfortably in the browser. For 10-MB-plus monolithic HTML or batch processing hundreds of files, a CLI tool like html-minifier-terser or @swc/html integrated into your build is more practical. For a single-file pass on a marketing page, an email template, or an SPA shell, the browser path is faster end-to-end because there's no Node setup.
Not perfectly. Minification is lossy with respect to formatting — removed comments and whitespace are gone. You can re-pretty-print the minified output with the HTML Formatter, which restores indentation and line breaks, but it cannot recover removed comments or omitted optional tags. Keep your source HTML in version control as the canonical copy.