HTML Minifier

No. Minification only removes characters the browser does not need, such as the whitespace between tags and comments that never render. Whitespace that affects layout, like the text inside pre and the spacing between inline elements, is preserved, so the rendered page looks identical before and after. If a layout depends on spacing in a way that worries you, the Safe level collapses each run of whitespace to a single space and never removes one.

Standard for almost everything: it removes the whitespace between tags and the attributes HTML5 already implies, which is what a normal build step does. Safe is the cautious option when spacing matters and you would rather not think about it. Maximum squeezes out the last few percent by dropping default and empty attributes and sorting attributes and class names, so it is worth a quick check that nothing selects on what it removed.

Yes. The CSS inside every <style> block and the JavaScript inside every <script> block are minified along with the markup, each with a toggle so you can turn them off. Inline style attributes and event handlers go through the same engines. On a real page the embedded code is often most of the weight, so this is where much of the saving comes from.

It means a piece of embedded code was left unminified, with every rule or statement intact, and it says why. The CSS engine cannot read nested rules and deletes them, and a declaration with a missing colon makes it lose the rule that follows, so any <style> block with either problem is preserved instead of minified. A script the JavaScript engine cannot parse, including anything using top-level await, is passed through the same way. Nothing is lost; those bytes are simply not compressed.

They work together. Minifying edits the HTML itself, removing content a compressor cannot know is unnecessary. Gzip or brotli then compresses whatever you send, collapsing repetition on the wire. You want both: minify first for the cleanest input, then let the server compress it. Judge the real gain by the gzip figure shown here.

It depends on how the source was written. Generously formatted markup with large inline styles and scripts can drop substantially, while already-tight pages shave less. Once gzip is in play the percentage shrinks, because compression had already recovered much of the whitespace, which is why the gzip number is the honest one.

No. The CSS engine is capable of following an @import and pulling the target in, and it is explicitly told not to. An @import stays in the output exactly as you wrote it, and no request is made for it, so pasting an internal page never sends anything to the network.

Not directly. This tool minifies standard HTML, which is what a browser receives. Template syntax such as {{ }} or {% %} is not valid HTML on its own, and attribute names are lowercased on the way out, so a directive like *ngIf comes back as *ngif. Minify the rendered output instead, or use a tool built for your template language.

No. Minified HTML is a build artifact, not source. Commit the readable template or document that you and your teammates edit, and generate the minified file as the final step before it is served. Checking in minified output makes reviews hard to read and merges painful.

No. Everything runs in your browser. The HTML you paste, any file you upload, and the result are processed locally, never transmitted or stored, and disappear the moment you close the tab, so even private or unreleased markup is safe.