Encoders & Utilities

CSS / JS Minifier

Strip comments and whitespace from CSS or JavaScript with auto-detect, byte stats, and copy/download.

What this does

CSS — strips /* comments */, collapses whitespace, removes trailing semicolons, tightens punctuation.
JavaScript — strips // line and /* block */ comments, collapses whitespace, tightens braces and parens. Preserves string and template literals.

Note: this is a safe regex minifier — no variable renaming (mangling) and no dead-code elimination. Use Terser / esbuild in your build pipeline for production-grade compression.

About this tool

CSS / JS Minifier removes everything the browser does not need: comments, redundant whitespace, trailing semicolons, and (for CSS) optional units after zero. Paste your file or drop it onto the page; the tool auto-detects whether you handed it CSS or JavaScript and applies the appropriate ruleset. The original and minified sizes are shown side by side with the percentage saved.

For CSS we follow a conservative rule set — safe across all browsers, no specificity changes, no shorthand rewrites that could change cascade behaviour. For JavaScript the minifier strips comments and collapses whitespace but does not rename variables or mangle identifiers (that would require a parser and risks breaking eval / dynamic property access). For aggressive minification (terser, esbuild, swc) use a build-time tool; this is the right tool for quick "make this smaller before pasting it into an email" tasks.

When to use this tool

Pre-deploy quick win. A small inline <style> or <script> that does not go through your bundler still benefits from minification.
Email and AMP templates. Inline CSS hits size limits; stripping whitespace can save 30–40%.
Copy-pasting into config. Long JS snippets in YAML or JSON config files become much more readable when minified.
Verifying byte savings before committing to a build-tool change.

What we deliberately do not do

No variable renaming, no dead-code elimination, no expression rewriting. These changes can break code that relies on identifier names (debug, monkey-patching, dynamic this), and the safety guarantees require a full AST-aware parser. For production builds use terser or esbuild; the savings are larger but the safety surface is much wider. This tool gives you the easy 50% with zero risk.

Frequently asked questions

How much smaller will my file be?

Typical savings: 30–50% for CSS, 20–40% for JavaScript. Heavily-commented source files can hit 60%+ savings. Already-minified inputs get little benefit (the minifier still runs idempotently — running it twice does not break anything). For more aggressive savings, pair with gzip/brotli compression at the server level, which is multiplicative with minification.

Does it work on TypeScript?

Not directly — TypeScript is not valid JavaScript and our minifier expects JS. Compile your TS to JS first (tsc, esbuild, swc) and minify the output. For type-annotated source, a TS-aware tool like esbuild or swc does both type-stripping and minification in one pass and is the right choice.

Will minified CSS break my layout?

No — the minifier preserves selector specificity, property order, and at-rule structure exactly. The only behavioural change is whitespace collapse and comment removal, both of which CSS treats as insignificant. If you see a visual diff after minification, you have hit a bug — file a report with the input.

Does this work for inline source maps?

It strips them (the //# sourceMappingURL= comment is a comment and goes away). For production you usually want to generate a separate .map file alongside the minified output, served conditionally. Our tool does not generate source maps — that requires a full parser and is the responsibility of a build pipeline. Use esbuild / terser for that workflow.