Minify HTML _

How HTML minification works

The minifier walks your input with a small state machine that distinguishes preserve-as-is regions (<pre>, <textarea>, <script>, <style>) from editable regions where whitespace and comments are safe to collapse.

1. Tokenize preserve blocks. The scanner reads the input character by character and flips into a preserve state when it hits an opening <pre>, <textarea>, <script>, or <style> tag. Everything inside those tags is kept byte-for-byte until the matching closer.
2. Collapse editable whitespace. In editable regions the scanner collapses every run of spaces, tabs, and newlines down to a single space, then trims leading and trailing whitespace around tag boundaries. The visible text reflows the same way the browser renders it.
3. Strip comments. <!-- ... --> blocks are removed when the toggle is on. IE conditional comments (<!--[if IE]> ... <![endif]-->) survive when the preserve-conditional toggle is on, because legacy email clients still rely on them.
4. Collapse boolean attributes. Verbose forms like checked="checked", disabled="disabled", and required="required" shrink to the bare attribute name. The HTML5 spec treats the bare form as semantically identical, so the rendered DOM is unchanged.
5. Report byte deltas. Both the original and the minified text are measured with new TextEncoder().encode(...).byteLength, the same UTF-8 byte count a CDN or HTTP server sees on the wire. The metric strip shows original size, minified size, saved bytes, and saved percent.

Why minify HTML

• Faster page loads. Smaller HTML reaches the browser sooner and the parser finishes earlier. On mobile networks the byte savings translate directly into a faster First Contentful Paint and a better Lighthouse performance score.
• Lower CDN egress bills. CloudFront, Cloudflare, and Fastly bill per gigabyte of egress. A 20 percent HTML reduction across millions of monthly views compounds into real savings on the invoice, before any image or script optimisation lands.
• Cleaner pull-request diffs. Pre-built static HTML committed to a repo gets noisy when every template tweak reflows indentation. Minified HTML in the dist folder produces tighter PR diffs that focus on real content changes instead of whitespace churn.
• Smaller embeds and snippets. Email templates, third-party widget snippets, and HTML stored inside JSON or YAML configs all benefit from the same byte cut. Minified embeds keep transactional emails under ESP size caps and shrink widget bundles.

Common applications

HTML minification shows up at the end of almost every static-site or JAMstack build pipeline, plus a handful of runtime contexts where the bytes matter more than the source readability.

• Static-site build steps: Eleventy, Hugo, Astro, and Next.js production builds run HTML through a minifier before writing to the dist folder so the deployed bundle is smaller than the source.
• Transactional emails: ESPs (SendGrid, Postmark, Mailgun) cap HTML body size and inline-CSS expansion balloons that count quickly. Minifying the body before sending keeps the message under the cap.
• Embedded widgets: third-party widgets and chat snippets shipped as inline HTML benefit from every byte cut because the host page has to download them on every visit.

A worked example

Paste a verbose 500-byte form snippet with two-space indentation, three line breaks between rows, an HTML comment block at the top, and a <input type="checkbox" checked="checked" />. With every option toggled on, the output collapses to around 300 bytes — roughly a 40 percent saving — while the rendered DOM tree stays byte-equal to the source.

Will minification break my HTML?

No, when used with the default toggles. The minifier preserves the contents of <pre>, <textarea>, <script>, and <style> tags verbatim, leaves IE conditional comments intact when that toggle is on, and only collapses whitespace the HTML5 parser already classifies as insignificant. The rendered DOM tree is byte-equal to the source. Aggressive toggles (remove-empty-attributes) can change behaviour for snippets that intentionally use value="" or alt="", so review the output if you flip them on.

Does this minify inline CSS and JS?

Not in this tool. Inline <style> and <script> bodies are preserved verbatim so the minifier never breaks a CSS rule or a JS statement by collapsing whitespace inside a string literal or a regex. For CSS-specific minification use a CSS Minifier; for JS use a JS Minifier. The HTML Minifier focuses on the markup itself.

How much can I save?

Typical savings on hand-authored HTML range from 10 to 30 percent, depending on how much the source uses indentation, blank lines, and verbose attribute forms. Pre-built static HTML from frameworks like Next.js often saves 15 to 25 percent because the framework already does some optimisation but leaves human-readable whitespace in place. Heavily commented templates and email-style HTML with deep nesting can hit 40 percent or more.

Is pre content preserved?

Yes. The minifier explicitly tokenizes <pre>, <textarea>, <script>, and <style> blocks as preserve-as-is regions and copies their contents byte-for-byte to the output. Whitespace, line breaks, and indentation inside those tags survive untouched, so code samples and ASCII art render exactly the same after minification.

Browser-side HTML minification keeps your build pipeline simple and your markup small. Paste any HTML above, tweak the option toggles, and copy or download the minified output — no upload, no account, no vendor library.