HTML Minifier

Most HTML minifiers are a black box. You paste your markup, hit a button, and get a smaller blob back with no say in what changed and no idea where the savings came from. This one hands you the controls instead. You pick what gets stripped, you watch the byte count move as you toggle each option, and you get a plain breakdown of how much you saved on comments versus how much you saved on whitespace. Most other minifiers do not show that split at all, and it is often the most useful thing on the page, because it tells you what was actually bloating your file.

It runs entirely in your browser. Paste a snippet, drop in an .html file, or open one from disk, and the minified version appears as you go. Nothing is uploaded, so you can run a client's private page through it without a second thought, and it keeps working offline once the page has loaded. Whatever options you flip, your pre, textarea, script, and style blocks come out exactly as they went in, down to the byte.

1. Get your HTML in. Paste it into the top box, drop an .html file onto that box, or click Open file and choose one. A single component, a chunk of a template, or a whole document from the doctype down all work. There is no size cap beyond what your browser can hold.
2. Pick what to remove. Four toggles: strip comments, keep conditional comments, remove the whitespace between tags, and collapse runs of whitespace. Leave them all on for a full minify, or turn one off when you want to hold onto something.
3. Read the result and the savings. The output updates live. Three tiles show the original size, the minified size, and the percent saved, all measured in real UTF-8 bytes. Below them, the breakdown splits that saving into comments and whitespace.
4. Take it with you. Copy the output with one click, or download it as a ready .html file.
5. Share your setup. The Share button copies a link that carries your exact toggle choices, so a teammate opens the tool configured the same way you left it.

If you just want to see it run, hit Load sample. It drops in a small page with a comment, an inline style block, and a pre full of messy spacing, so you can watch what gets flattened and what gets left alone.

The four options map to the only things a minifier should ever touch:

• Remove comments deletes every <!-- ... --> note. The browser downloads comments and then ignores them, so in production they are dead weight.
• Keep conditional comments is the safety catch on that. Some comments are not really comments, and this leaves those in place while every ordinary note still goes (the next section explains the difference).
• Remove whitespace between tags strips the indentation and line breaks sitting between one tag and the next. On hand written HTML that is usually the biggest single saving, since a deeply nested page is mostly indentation by byte count.
• Collapse runs of whitespace turns any stretch of spaces, tabs, and newlines in your text into one space, which is what the browser does when it renders anyway.

Turn everything off and the tool hands your HTML straight back, unchanged. Turn a single option on and you see exactly what it costs you in bytes. That control is the whole point, and you never have to open a config file to get it.

After a minify, most tools show you a single number, the total saved, and leave you to guess what caused it. Ours splits that total in two, and getting the split honest is the thing I care most about on this page.

That guessing wastes real time, because a developer sees a page shrink forty percent and assumes the whitespace did it, when half of the drop was a giant block of commented out markup a template left behind. If comments are the bulk of your saving, that is a nudge to clean them out of your source. If it is nearly all whitespace, your editor or build step is the place to look. Everything a minifier removes is either a comment or whitespace, so those two numbers account for the whole saving with no rounding games behind them.

In HTML most whitespace is just indentation you can throw away, but inside a few elements it is content the page actually depends on. A naive minifier cannot tell the two apart, so it flattens both and quietly breaks your page. Four elements hold whitespace that means something, and this tool copies each of them out verbatim:

• pre renders spaces and line breaks literally. Collapse the whitespace inside one and your carefully indented code sample becomes a single run on line.
• A prefilled textarea shows its contents as the field's default value, whitespace and all, so flattening the newlines changes what the user sees typed in the box.
• script carries your JavaScript. It mostly ignores whitespace, but template strings, regexes, and any line continued with a backslash break the moment you touch them.
• style is your CSS, where most whitespace is safe to squash but content strings and a few values are not.

The tool scans your HTML one character at a time, and the instant it hits one of those opening tags it copies everything through the matching close tag with no changes at all. Only the markup outside those zones gets collapsed, so a code block never turns to mush.

Not every <!-- ... --> is a throwaway note. A conditional comment looks like one but is actually markup that only old versions of Internet Explorer act on, like a <!--[if lt IE 9]> wrapper around a fallback script. Modern browsers skip it, but IE 8 reads it as a live instruction to load that file. Strip it as an ordinary comment and you silently remove a fallback for the exact browsers that needed it. So "keep conditional comments" stays on by default, and while it is on, anything starting with <!--[if ... survives while ordinary notes go. Dropped IE support and want those gone too? Turn the toggle off and they go with the rest.

If your server already gzips its responses, why minify at all? The two work differently and stack. Minifying edits the source, deleting characters that were only ever there for a human to read. Gzip and Brotli compress in transit, then expand the file on arrival. They overlap, since gzip is good at the repetitive indentation a minifier deletes outright, so minifying a file that is about to be compressed wins you only a few percent on top, which is still worth doing because you only pay the cost once. If your server is not compressing responses yet, turn that on first, because it is a much bigger lever.