HTML-pienentäjä

Minify and compress HTML in one place

This HTML minifier strips out everything a browser doesn't need to render your page — comments, redundant whitespace, and the line breaks and indentation between tags — so the file you ship is physically smaller but looks and behaves exactly the same. Paste your markup or drop in an .html file and the compressed result appears instantly, with the exact bytes and percentage you saved.

It doubles as an HTML compressor and an HTML beautifier: a single toggle flips between minifying a page and un-minifying one, so the same tool that crunches your markup down can also expand a minified page back into clean, indented code. Everything runs in your browser — no upload, no account, no limits.

What it removes — and what it never touches

When you minify HTML, the tool removes comments (<!-- … -->), collapses runs of whitespace, trims the gaps between block-level tags, collapses boolean attributes (disabled="disabled" becomes disabled) and can optionally drop redundant closing tags like </li> and </td>. Conditional comments (<!--[if IE]>) are always preserved.

Crucially, it's safe. The contents of <pre>, <textarea>, <script> and <style> are protected before anything is stripped, and the single spaces between inline elements — links, <span>s, <strong> — are kept, so your text never runs together. This is the same safety model used by kangax's HTMLMinifier, the most widely deployed HTML minification library, maintained on GitHub with over 5,000 stars. Quoted attribute values are protected too, so a title with double spaces stays exactly as written.

Minify or beautify — a true two-way tool

Need to read a page that's been squashed onto one line? Switch to Beautify mode to unminify HTML: the tool re-indents the markup, puts tags on their own lines and makes the structure easy to scan again. Pick 2-space, 4-space or tab indentation to match your project's style.

Because minifying and beautifying are reversible, you can paste minified production HTML, read it, tweak it, and minify it again — all without leaving the page or installing anything. Tools like PrettyDiff and Prettier do similar HTML formatting, but they require Node.js or a browser extension. This tool works immediately in any browser on any device, including mobile, with no setup.

See the bytes you save — including gzip

A stats bar reports the original size, the output size, and the bytes and percentage saved, so you always know exactly how much smaller your HTML got. Sizes are measured in real UTF-8 bytes, not character counts, so they match what your server actually serves.

It also shows a gzipped figure computed locally in your browser. Minification and gzip stack — minify the source, then let your host compress it — and seeing both numbers makes the combined win clear. Google's PageSpeed Insights and web.dev both recommend doing both steps. Most competing HTML minifiers show only the minified byte count; this tool shows the gzip estimate too, which is the number that actually determines how fast your page loads over the network.

Minify inline CSS and JavaScript, safely

Real-world pages carry styling and behaviour inline. Turn on Minify inline CSS and every <style> block is compressed the same way a dedicated CSS minifier would — comments and whitespace removed, with strings, url() and calc() protected so nothing breaks.

Minify inline JS tidies <script> blocks conservatively: it strips comments and collapses indentation but deliberately keeps line breaks, so JavaScript that relies on automatic semicolon insertion can't be corrupted. Scripts marked as JSON, templates or other non-JavaScript types are detected and left untouched. This combined approach beats running separate tools like a CSS Minifier and a JS Minifier sequentially, since each one can misread context when applied to a mixed HTML file.

How this compares to HTMLMinifier.com, Minifier.org, and Willpeavy

The most popular competing HTML minifiers — HTMLMinifier.com, Minifier.org, and Willpeavy.com's HTML minifier — all process your HTML server-side. Every snippet you paste is sent over the network to a third-party server. For public test HTML this is fine; for client work, unreleased pages, or any HTML that includes auth tokens, private content, or form data, it's a real privacy risk. Minifycode.com has the same limitation.

This tool runs entirely in your browser. The JavaScript that minifies your HTML is downloaded once when the page loads, then runs locally — no server involved, no data transmitted. For WordPress sites, it covers the gap that plugins like WP Rocket, LiteSpeed Cache, and Autoptimize don't reach: individual template snippets, custom blocks, and HTML emails that bypass the plugin's automatic minification. Use it as your quick-check before committing a template change, or as the primary minifier for projects that don't use a build system.

What minification actually removes — the HTML spec perspective

The HTML5 specification makes several categories of content genuinely inert, which is what minification exploits. Whitespace-only text nodes between block-level elements — the newlines and spaces that make source indentation readable — are ignored during layout. The browser's HTML parser creates them as DOM text nodes, but the CSS box model discards whitespace-only text nodes that appear between block boxes, so collapsing them has zero rendering consequence. HTML comments (<!-- … -->) are parsed into Comment nodes that are invisible to the render tree and can never be styled, selected, or reached by most JavaScript (unless code explicitly calls document.createNodeIterator with the SHOW_COMMENT filter, which almost no production code does).

Optional closing tags are another safe target defined by the HTML5 parsing rules. The specification explicitly lists elements whose end tags may be omitted when a specific following tag makes the close unambiguous: </li> when another <li> follows, </p> before a block-level element, </td> before another <td> or </tr>, and similarly for </dt>, </dd>, </th>, </tr>, </colgroup>, </tbody>, </tfoot>, </thead>, </head>, </body>, and </html>. All major browsers implement these omission rules and have done so since well before HTML5 was finalised. Boolean attribute optimisation is equally safe: the HTML spec defines boolean attributes by the presence of the attribute name alone — disabled, checked, readonly, required, multiple, novalidate, and others. The value is irrelevant; disabled="", disabled="disabled", disabled="false", and bare disabled are all identical. Minifiers reduce all forms to the bare attribute name, typically saving 8–12 bytes per boolean attribute.

Attribute quote removal is valid under the HTML5 spec when the attribute value contains no whitespace, double-quote, single-quote, backtick, equals sign, or angle bracket. Values like class=container, id=header, and type=text are perfectly legal unquoted HTML. Conservative minifiers skip this optimisation because a single missed special character breaks parsing; aggressive settings in libraries like html-minifier-terser apply it with a character-class check on every value before deciding.

HTML size, HTTP, and how minification fits the delivery chain

HTML is almost always the first resource the browser fetches on a page load. The browser cannot discover CSS, JavaScript, images or fonts until it has parsed at least the <head> of the HTML document — so the HTML response sits on the critical path of every subsequent resource. A larger HTML file means more bytes before the parser can emit the first link preload or discover a stylesheet, which delays First Contentful Paint (FCP) and contributes to a higher Time to First Byte (TTFB) as perceived by the client (since the server must transmit more bytes before the first meaningful content arrives). This is why Google's Lighthouse and PageSpeed Insights both flag unminified HTML alongside unminified CSS and JavaScript.

Under HTTP/1.1, each TCP connection carries overhead for the three-way handshake, TLS negotiation, and TCP slow-start, which means the first few kilobytes of every connection are the most expensive. A bloated HTML file that pushes past one or two TCP initial congestion window sizes (roughly 14 KB each) forces the server to wait for an ACK before sending further data, adding a full round-trip of latency. HTTP/2 reduces this with multiplexed streams and HPACK header compression, but the HTML body — unlike headers — is not compressed by the protocol layer; body compression still depends on GZIP or Brotli at the content-encoding level. Even with Brotli enabled (which achieves 15–25% better compression than GZIP on HTML text), minification remains additive: it removes redundant bytes before the compression algorithm runs, which slightly improves both compression ratio and the decompression work the browser must do. A 100 KB HTML file that gzips to 22 KB might gzip to 19 KB after minification — a seemingly modest gain that adds up across thousands of page views per day.

The interaction between minification and CDN edge caching is also relevant. When a CDN caches a response, it stores the compressed bytes. A minified-then-compressed origin response occupies less edge-cache storage, which can reduce cache eviction for high-cardinality URL sets (e.g., e-commerce product pages with many URL parameters). For HTML that is not cacheable — personalised pages, logged-in dashboards — minification directly reduces the bytes the origin must push over the wire on every single request, with no caching benefit to offset the cost of skipping it.

Inline CSS and JavaScript minification: trade-offs and techniques

Inline resources present a distinct set of trade-offs compared to externally linked files. An external .css or .js file can be cached by the browser independently from the HTML; on repeat visits the file is served from the local disk cache and generates zero network bytes. An inline <style> or <script> block is part of the HTML document, so if any part of the HTML changes, the entire document must be re-fetched — the browser cannot cache a fragment of an HTML response. This is the fundamental trade-off of inlining: you save an HTTP request on the first load but sacrifice independent cacheability. For resources that change frequently, the penalty compounds across every page view.

Despite that caveat, critical CSS inlining is a widely recommended performance technique. The render-blocking nature of external stylesheets means the browser must fetch, parse, and apply a CSS file before it can paint anything. Inlining only the CSS needed to render above-the-fold content — typically 5–15 KB — eliminates that render-blocking request and can dramatically improve Largest Contentful Paint (LCP). Tools like Critical (Node.js) and PurgeCSS automate the extraction; the resulting inline CSS should itself be minified as part of the same build step. When you minify inline CSS, the minifier shortens property values where the spec allows it: #ffffff becomes #fff, font-weight: normal becomes font-weight: 400, and margin: 10px 10px 10px 10px collapses to margin: 10px. These micro-optimisations are individually tiny but collectively meaningful in large CSS blocks.

Inline JavaScript minification is more conservative than what dedicated tools like Terser or esbuild do with standalone .js files. Variable name mangling — replacing longVariableName with a — requires the minifier to build a full scope analysis of the code, which is only safe when the entire JS bundle is being processed as a unit. Minifying a single inline script block in isolation cannot safely mangle variable names because the script may read from or write to global variables used by external scripts loaded elsewhere on the page. Consequently, safe inline JS minification strips comments, collapses whitespace, and removes unnecessary semicolons, but leaves identifiers intact. Dead code elimination — removing branches that can never execute — is similarly off-limits without whole-program analysis. For maximum JS minification, move the code to an external file and run it through Terser's full bundle-level pipeline; use inline JS minification to handle the residual glue code and analytics snippets that must stay inline.

HTML minification in build toolchains and real-world savings

Modern JavaScript build tools handle HTML minification as part of their production output pipeline. html-minifier-terser — the actively maintained successor to kangax's original html-minifier — is the most widely used Node.js library for this task. Its key options map directly to the techniques above: removeComments, collapseWhitespace, removeOptionalTags, collapseBooleanAttributes, removeAttributeQuotes, minifyCSS, and minifyJS. Webpack applies it via html-webpack-plugin combined with html-minimizer-webpack-plugin, which wraps html-minifier-terser and runs on every emitted HTML file. Vite minifies HTML in production builds using htmlnano under the hood, with preset levels from safe to aggressive. Astro — the static site generator this tool is built with — runs htmlnano on SSG output by default, so every statically generated page is minified without any explicit configuration. Rollup users can add @rollup/plugin-html and chain it with a minification transform.

Development builds deliberately skip minification. Readable HTML source is essential for inspecting the DOM in browser DevTools, matching elements to source lines, and diagnosing layout bugs without the cognitive overhead of decoding compressed markup. Unlike JavaScript — which has a mature source map standard (.map files) that lets DevTools show the original pre-minified code — HTML has no equivalent source map specification. Minified HTML in production is therefore genuinely harder to debug in the browser's Elements panel, which is another reason to only apply minification in production builds and to keep a beautified copy accessible for inspection.

In terms of real-world savings, minification alone typically reduces raw HTML size by 5–15%. A large e-commerce product page full of CMS-generated template comments, trailing spaces on every line, and verbose boolean attributes might drop from 80 KB to 68 KB — about 15% — before compression. After GZIP, the savings narrow because gzip's LZ77 algorithm is already very effective at compressing repetitive whitespace patterns: the unminified 80 KB page might gzip to 18 KB and the minified 68 KB page might gzip to 16 KB — a 2 KB gap. The compressed saving is real but smaller in percentage terms than the uncompressed gain. For Brotli, the gap is similar. Where minification consistently pays off beyond the bytes-saved calculation is in parsing speed: a browser's HTML tokeniser processes fewer characters, which marginally reduces Time to Interactive (TTI) on very large documents, and reduces the peak memory allocated for the initial parse buffer — measurable on low-memory mobile devices that are already under pressure from running scripts and layout concurrently.