Minify HTML files in your browser
Minifies the markup and tells you the truth about what that is worth: less than turning on gzip, which most hosts already have.
or browse your device. Everything is processed on this device
No HTML to hand?
Got it on your clipboard?
How to minify HTML
One page or a whole export. Nothing is uploaded, so a file with customer data in it is as safe here as it is on your disk.
The defaults are the safe ones: whitespace and comments only. Turn on the inline and aggressive options if you want the rest.
The result panel breaks the saving down into whitespace, comments, inline CSS and inline JS, so you can see whether it was worth it.
Same file name, same encoding, ready to upload. If minifying made the file larger, you get the original back instead.
Read this before you minify anything
Minifying HTML typically saves 10 to 25% of the source. Then your server gzips or brotlis the response and saves 70 to 80% of whatever is left. Those two numbers are not in the same league, and they multiply rather than compete.
So the most useful thing this page can tell you is this: if your host already compresses responses, and almost all of them do, minifying buys you very little. A 60KB page might land at 48KB minified, and after brotli the difference between the two is a couple of hundred bytes. If your host does not compress responses, turning that on beats anything this tool can do to your markup, by a factor of about five. Check first, minify second.
The other thing worth knowing is that the weight of a web page is almost never its HTML. It is the images and the JavaScript. If a page is 2MB and 40KB of that is markup, you have an image problem, not a markup problem, and shaving 8KB off the HTML fixes nothing you can feel. Run the images through the JPG or WebP tools instead: that is where the megabytes are.
Where minifying does earn its keep: emailed HTML, where nothing gzips anything and every byte is stored forever; files served from somewhere with no compression at all; and build pipelines that have no minify step and are not going to get one. This site runs a minifier over its own pages at build time for exactly that last reason.
HTML minification FAQ
Does minifying HTML actually speed up my site?
Barely, if your server already compresses responses. The saving is real but it is 10 to 25% of a file that gzip was going to shrink by 70 to 80% anyway, so the measurable difference on a page load is usually under a few milliseconds. What speeds up a site is fewer and smaller images, less JavaScript, and compression being switched on at all.
Will minifying break my page?
It should not, and the tests are written around the ways it could. Whitespace between inline elements is kept as a single space, so words never end up glued together. The contents of pre, textarea, script, style and anything with white-space: pre set inline are left byte for byte. Conditional comments survive. The one setting that can visibly change things is Aggressive rewrites, which is off by default.
Is minifying HTML the same as compressing it?
No, and the difference is the whole point of this page. Minifying rewrites the markup so it says the same thing in fewer characters, and the result is still an HTML file you can open. Compressing means gzip or brotli, which produces something a browser has to unpack before it can read it, and which your server does on the fly for every response. Minifying is permanent and small. Compression is invisible and large.
Should I minify or gzip?
Both, and gzip matters far more. Compression at the server is the single biggest win available to you and it costs nothing to turn on. Minifying is what you do afterwards, to the file that is already being compressed, for a few extra percent. If you can only do one, do gzip or brotli.
Is minified HTML still valid?
Yes. Everything on by default is whitespace and comment handling, which the spec has nothing to say about. Aggressive rewrites uses features that are also valid: unquoted attribute values, omitted end tags for elements like li and p, and default attributes left out. A validator passes all of it. It is harder to read, which is why it is optional.
How do I minify HTML without a build step?
Drop the file here, take the output and upload it. That is the whole workflow, and it is the right one for a hand-written page, an email template or a static file you edit twice a year. If you deploy from a build, put the minifier in the build instead so it is never a step someone can forget.
Does it minify the CSS and JavaScript inside my page?
The CSS properly: comments out, whitespace collapsed, the last semicolon in a block dropped, six-digit hex colours shortened, units removed from zero lengths. The JavaScript only gets trimmed, meaning comments and indentation are removed and nothing else. A real JS minifier has to understand the grammar to move code around safely, and automatic semicolon insertion punishes anything that half-understands it.
What happens to my JSON-LD and structured data?
Left alone beyond stripping the blank lines around it. Anything in a script tag with a type this tool does not recognise as JavaScript, including application/json, application/ld+json and template blocks, is copied out exactly as it went in.
How much smaller will my file get?
Usually 10 to 25%. Hand-written and generated pages with deep indentation do best; something already run through a build is often within a byte or two of where it started. If the output would be larger than the original, you get the original back and the tool says so.
Other compressors
Same format joins the queue. Anything else re-routes to its own tool.