Minify CSS to Speed Up Your Site
Strip comments and extra whitespace from CSS to shrink the file size instantly.
Your stylesheet stays on your device
Nothing to delete afterwards
Safe for unreleased interfaces
Works in every modern browser
How it works
- 1
Paste your CSS
A stylesheet, a component’s styles, or a block you want smaller before it ships.
- 2
Check the sizes
Compare minified and compressed, and read any warnings before replacing the original.
- 3
Copy the output
Take it into a build output, a `<style>` block, or a template.
Why use this tool
Declaration order preserved
Nothing is reordered, because the cascade breaks ties by position and moving a rule changes what renders.
Fallbacks left intact
A property declared twice is usually a deliberate fallback for older browsers, not duplication to delete.
No unsafe shorthand merging
Collapsing longhand properties into a shorthand resets the sides you did not mention, so it is not done silently.
Compressed size shown
The minified figure next to the gzip figure, because only the second is what the browser downloads.
Parsed where it belongs
A browser is already a CSS engine, so no request is needed and the file simply stays in the page.
No limits and no sign-up
Run it on one rule or on a framework build, as often as you like.
Order is meaning, which limits what a minifier may safely do
CSS resolves competing declarations by specificity first and by document order second: when two rules have equal weight, the one written later wins. That makes position part of the meaning of a stylesheet, and it is why aggressive optimisation is riskier here than in most languages. A tool that groups all rules sharing a selector, or sorts declarations for better compression, or merges two blocks that happen to declare the same properties, can produce a file that is byte-for-byte smaller and visually different — because a rule that used to come last no longer does. The reductions that are always safe are the ones that do not move anything: removing whitespace, removing comments, and shortening values whose meaning is fixed. Anything that reorders needs to understand your whole cascade, which a text-level tool does not.
The same property twice is usually a fallback, not a mistake
This is the specific case where "remove the duplicate" breaks a page. Declaring a property twice in the same block is the standard way to support older browsers: `color: #ccc` followed by `color: rgba(0, 0, 0, .5)` means a browser that understands the second uses it and one that does not falls back to the first, because an unparseable declaration is discarded rather than fatal. The same pattern covers `display: -webkit-box` before `display: flex`, a pixel width before a `calc()` width, and a solid colour before a gradient. A minifier that sees two declarations of one property and keeps only the last has removed the support; one that keeps only the first has removed the feature. Both are wrong, and the correct behaviour is to leave the pair alone.
Merging longhand into shorthand resets what you did not mention
This is the subtlest correctness trap in CSS optimisation. If a rule sets `margin-top` and `margin-left`, collapsing them into a single `margin` declaration does not leave the other two sides as they were — a shorthand sets every property in its group, so the unmentioned sides are reset to their initial values, discarding anything inherited or set by an earlier rule. `background` is worse, because it resets a long list including `background-size` and `background-position`, so a merge can silently undo a `background-size: cover` declared elsewhere. `font` behaves the same way with `line-height`. The saving from these merges is small and the failure is a layout that looks fine in the file and wrong in the browser, which is why this tool does not perform them.
The large win is unused rules, and it is harder than it looks
Minifying a stylesheet trims perhaps a fifth of it. Removing the rules a page never uses can trim ninety percent, because a general-purpose framework ships styles for every component and every variant while a given page uses a handful. That is where the real size is — and it is genuinely difficult to do safely, for a reason specific to CSS. A purge tool works by scanning your templates and code for class names and keeping the rules that match. It cannot see a class name that was assembled at runtime, so `"btn-" + variant` looks like nothing at all, and the rule for `btn-danger` gets deleted while the code that needs it still runs. Anything built dynamically, injected by a third-party widget, or added by JavaScript after load has to be listed as an exception, and that list is what makes purging a project rather than a switch.
CSS blocks rendering, so its size costs something different
Why the size matters is not the same for CSS as for scripts. A browser will not paint content that a pending stylesheet might restyle, so a stylesheet in the head is render-blocking: until it has arrived and been parsed, the page stays blank. That makes the cost of CSS weight land squarely on first paint, which is the part of loading users notice most, and it is the strongest argument for keeping the critical stylesheet small. It also explains why the standard advice is to inline the small amount of CSS needed for the visible area and load the rest asynchronously — a structural change that helps far more than minification does. If you can only do one thing, splitting the stylesheet beats compressing it.
Why minifying locally matters for this kind of file
A stylesheet is less obviously confidential than application code and it still describes more than people notice. Class names map your interface: they name components that have not shipped, variants belonging to an experiment that is still running, panels only administrators see, and features behind a flag. Comments in CSS are candid in a way comments elsewhere are not — a client name, a note about which browser broke, a reminder that a value is a workaround for a bug in a specific version. Pasting a production stylesheet into a hosted minifier hands all of that over for a size reduction available locally. This tool processes the file in the page and transmits nothing, which you can confirm in the Network tab of your developer tools.
Common mistakes to avoid
- Removing a property declared twice in one block. That is almost always a deliberate fallback for older browsers — keeping only one of the pair removes either the support or the feature.
- Merging longhand properties into a shorthand. A shorthand sets every property in its group, so the sides you did not mention are reset to their initial values rather than left alone.
- Letting a tool reorder or group rules for better compression. The cascade breaks ties by document order, so a smaller file can render differently.
- Expecting minification to solve stylesheet size. Unused rules are usually the bulk; minification trims about a fifth of what an unused-CSS pass would.
- Purging unused CSS without listing dynamic class names. A name assembled as `"btn-" + variant` is invisible to a scanner, so the rule it needs gets deleted while the code still runs.
How it compares
| Aspect | This tool | Online minifiers | A build pipeline |
|---|---|---|---|
| Stylesheet sent to a server | Never | Usually yes | No |
| Preserves declaration order | Always | Usually | Usually |
| Keeps browser fallbacks | Yes | Varies | Configurable |
| Removes unused rules | No | No | With a purge step |
| Compressed size shown | Yes | Rarely | With a plugin |
| Price | Free | Free / paid tiers | Free |
Features
Whitespace and comment removal
Everything the parser ignores is dropped, including the blank lines that group your rules.
Safe value shortening
Colours reduced to their shortest equivalent form and zero units trimmed, where the meaning cannot change.
Order-safe by design
Rules keep their positions, so specificity and source order continue to resolve the same way.
Both sizes reported
Raw and compressed, since compression already collapses most of what minification removes.
Modern syntax understood
Custom properties, nesting, container queries, and layers pass through without being mangled.
Handles large stylesheets
A whole framework build minifies without an upload or a size cap.
Nothing to install
No build tool, no runtime, no dependencies — it runs on the web page.
Arabic and RTL ready
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 stylesheet that is not going through a build step.
Web performance engineers
Reducing the render-blocking stylesheet that gates first paint.
Email developers
Compacting styles that must be inlined into a template with a size limit.
Anyone embedding a style block
Getting component styles small enough to inline in a page head.
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.