CSS Minifier

Less than most people assume. Compression algorithms are extremely good at the exact redundancy that minification removes: repeated whitespace, repeated property names, repeated selector patterns. Measured on real stylesheets, minification typically cuts 15 to 25% of raw bytes, but once both the minified and the pretty version are gzipped, the gap between them often narrows to a few percent. It is still worth doing in a build, because a few percent on a render-blocking resource is real, but it is not where the big wins are.

Deleting rules you do not use. Most sites load a CSS framework and apply a small fraction of it, and the dead selectors survive every minifier because a minifier has no idea what your HTML contains. Tools that scan your templates and remove unmatched selectors routinely cut a stylesheet by 80 or 90%. After that, splitting the critical above-the-fold CSS from the rest matters more than any byte-level trick.

Yes, particularly if your CSS is unusual. This is a whitespace and comment transform driven by regular expressions rather than a full CSS parser, which is why it is instant and dependency-free. The consequence is that it cannot reason about context: it does not know that a comma inside a quoted content string is data rather than a separator, and it does not know that a space before a colon might be a descendant combinator. On ordinary stylesheets it is fine. On clever ones, diff the output.

You can, but you should not. Minified CSS is a build artefact. Once it is the only copy, you have lost the comments, the structure, and the ability to review a change in a diff. Keep the readable stylesheet in version control, minify as part of your deploy, and never hand-edit the output, because the next build will overwrite whatever you changed.

No. The transformation runs in your browser as a set of string operations. Stylesheets sometimes contain internal URLs, unreleased class names, or comments about a client, so nothing is transmitted or stored.