Minify HTML in One Click
Collapse whitespace and strip comments from HTML to shrink its file size instantly.
Your markup stays on your device
Nothing to delete afterwards
Safe for unreleased copy
Works in every modern browser
How it works
- 1
Paste your HTML
A full document, an email template, or a fragment a server renders into a page.
- 2
Read the report
Compare minified against compressed size, and check the warnings before replacing the original.
- 3
Copy the output
Take it into a build output, a template file, or an inline document.
Why use this tool
Significant whitespace kept
Space between inline elements is a rendered word gap, so it is preserved rather than collapsed away.
pre and textarea untouched
Both preserve whitespace by specification, and reformatting their contents changes what the visitor reads.
Closing tags left in place
Optional tags are removed by minifiers relying on parser error recovery, which this tool does not gamble on.
Script and style handled correctly
Embedded blocks are different languages, and a string containing a closing script tag is not misread as markup.
Honest about the gain
The document is usually the smallest of your three assets, and the numbers shown say so.
Nothing leaves the browser
The markup is processed on this page, so draft copy and staging URLs are not handed to a server.
Whitespace in HTML is sometimes significant, and that is the whole difficulty
In CSS and JavaScript, whitespace outside a string carries no meaning and can be removed wholesale. HTML does not work that way. A run of spaces between two inline elements collapses to a single space rather than to nothing, and that surviving space is a rendered word gap: strip the newline between `<span>Total</span>` and `<span>Price</span>` and the two words run together on screen. The same applies between an anchor and the text after it, between adjacent `<a>` items in a nav, and around `<img>` and `<button>`. It is why a minified page can suddenly read “SignoutSettings”, and why the safe rule is to collapse whitespace only between block-level elements, where the browser was never rendering a gap in the first place. Deciding which case you are in requires knowing each element’s display value, which depends on your CSS — so a tool that only sees the markup has to be conservative, and this one is.
pre and textarea preserve whitespace by specification
Two elements make whitespace load-bearing in the strongest sense. Inside `<pre>`, every space and newline is rendered as written, which is why code samples and ASCII layout survive there and nowhere else; reindenting a `<pre>` block changes the code your reader sees, and collapsing it destroys the sample entirely. `<textarea>` behaves the same way for its initial value, so the whitespace in a form’s default text is content, not formatting — and a leading newline immediately after the opening tag is stripped by the parser, which means a minifier that adds or removes one silently changes what the user finds in the field. `<script>` and `<style>` contents are also off-limits to markup-level whitespace rules, for a different reason covered below. Any minifier that treats the document as one uniform stream of tags and text will eventually mangle one of these.
HTML is forgiving, and that makes aggressive minification riskier rather than safer
HTML has no parse errors in the sense that CSS and JavaScript do. Omit `</p>`, omit `</li>`, omit `</tbody>`, drop the quotes around an attribute, and a browser will recover and build a tree anyway — the specification defines exactly how. Minifiers exploit that: removing optional closing tags is a real byte saving, and the specification says it is legal. The catch is that recovery is only guaranteed identical for markup that was already valid. In a document where a tag is already unbalanced, or where a `<div>` sits inside a `<p>`, removing optional tags shifts where the parser decides an element ended, and the resulting tree is a different tree — usually visible as content that jumps outside the box it belonged in. It is also markup that other things read: a fragment with implied closings can break a downstream template engine, an email client, or a scraper that uses a stricter XML parser. This tool leaves closing tags alone, because the saving is small and the failure is structural.
Embedded script and style are different languages inside the same file
A `<script>` or `<style>` block is not markup, and the parser switches modes when it enters one. That has a specific consequence that catches naive tools: inside a classic script, the parser looks for the literal characters `</script` and ends the element there, even when they sit inside a JavaScript string. Code that writes `document.write("</script>")` therefore terminates its own block, and the standard fix is to break the sequence as `"<\/script>"`. A minifier that rewrites string quotes or re-escapes text without understanding this can create the sequence where it did not exist, and the page truncates from that point on. The mirror case is a minifier that treats script contents as text and collapses whitespace inside it, which is harmless until it meets a template literal or an unterminated line where a newline was doing the work of a semicolon. Handling these blocks correctly means running a real JavaScript and CSS pass on them, not a markup pass.
HTML is the asset where minification buys the least
It is worth saying plainly, because it changes what you should spend effort on. Of the three text assets a page loads, the document is usually the smallest, and it is the one you generally cannot cache — a stylesheet and a bundle are fingerprinted and cached for a year, while the HTML is fetched fresh on nearly every visit. That sounds like an argument for shrinking it, and partly it is, but the numbers are modest: markup compresses extremely well because it repeats the same tag names and attribute patterns hundreds of times, so gzip or Brotli on the server already removes most of what a minifier would. The real wins in a document are structural — fewer inline data blobs, no giant base64 images pasted into the source, no server-rendered state dumped into a script tag. If your HTML is genuinely large, minifying it is not the fix; finding out what is in it usually is.
What a page’s markup gives away, and why that argues for local processing
Markup is the most quietly revealing of the three files. It carries the copy itself, including headings and product names for a launch that has not happened, and comments in HTML are where teams leave the frankest notes — a ticket number, a staging hostname, a reminder that a section is hidden until legal approves it, the name of the agency that wrote the template. It carries hidden form fields, analytics identifiers, sometimes a CSRF token, and often an email address that is not published anywhere else. Pasting a real page into a hosted minifier hands all of that to a third party in exchange for a byte reduction you have already been told is the smallest of the three. Everything here happens in the page you are reading: open your browser’s developer tools before you paste, and you will see the request count stay where it was.
Common mistakes to avoid
- Collapsing whitespace between inline elements. That space is a rendered word gap, so removing it runs two words together on screen even though the markup still looks correct.
- Reformatting the contents of `pre` or `textarea`. Both preserve whitespace by specification, so reindenting changes the code sample or the form’s default text.
- Removing optional closing tags to save bytes. Recovery is only guaranteed identical for already-valid markup, and in anything unbalanced the parser ends elements somewhere else.
- Letting a markup-level pass touch `script` contents. The literal `</script` ends the element even inside a JavaScript string, so re-escaping can truncate the page.
- Expecting minification to fix a large document. Markup compresses very well, so the server has already taken most of it — an inline data blob is the usual real cause.
How it compares
| Aspect | This tool | Online minifiers | A build pipeline |
|---|---|---|---|
| Markup sent to a server | Never | Usually yes | No |
| Keeps inline word gaps | Always | Varies | Configurable |
| Leaves pre and textarea alone | Yes | Varies | Usually |
| Removes optional closing tags | No | Often | Configurable |
| Compressed size shown | Yes | Rarely | With a plugin |
| Price | Free | Free / paid tiers | Free |
Features
Comment removal
Development notes and section markers go, while conditional comments that still do work are kept.
Safe whitespace collapsing
Runs of space are reduced only between block-level elements, where no gap was ever rendered.
Attribute tidying
Redundant type attributes and empty attribute values are dropped where the HTML specification makes them the default.
Quote handling you can see
Attribute quotes are only removed when the value cannot possibly need them, and never on the last attribute.
Both sizes reported
Raw and gzip, because server compression already collapses most of what minification removes from markup.
Large documents supported
A rendered page of any size minifies without an upload or a size ceiling.
Nothing to install
No build tool, no runtime, no dependencies — it runs in the web page.
Arabic and RTL ready
The full interface in eight languages, including right-to-left Arabic.
Secure by default
Served over HTTPS, with no content tracking and no third-party upload.
Who uses it
Front-end developers
Shrinking a template that does not pass through a build step.
Email developers
Getting a template under a client’s size limit without breaking its table layout.
Backend developers
Tidying a server-rendered fragment before it is returned to the page.
Anyone inlining a document
Compacting markup that has to be embedded somewhere with a hard size cap.
Frequently Asked Questions
No. Everything runs locally in your browser — your text is never uploaded, stored, or shared.
Yes — completely free, with no account and no limits.