CSS & JS Minifier
Strip comments and whitespace from CSS, JavaScript, HTML and JSON, with a live report of exactly how many bytes you saved and what the file should weigh after gzip.
Photo by Fotis Fotopoulos on Unsplash
Code minifier
Key takeaways
- Minification and compression multiply — minified source gzips smaller than unminified source.
- JavaScript costs more than its transfer size: parse, compile and execute add roughly 1 ms per kilobyte on mid-range phones.
- Always minify in a build step and keep the readable source in version control.
What minification actually removes
Minification strips everything a machine does not need: comments, indentation, line breaks, redundant semicolons and unnecessary whitespace. The program behaves identically; it is simply shorter.
Typical savings before compression:
| Language | Typical reduction | Why |
|---|---|---|
| CSS | 20–35% | Heavy whitespace and comments |
| JavaScript | 30–60% | Comments plus name mangling in full minifiers |
| HTML | 10–20% | Mostly inter-tag whitespace |
| JSON | 15–40% | Indentation only |
This tool is conservative by design. It removes comments and whitespace safely but does not rename variables, dead-code eliminate or tree-shake. That is what a real build-time minifier does, and it needs a full parser and scope analysis. Use this for quick one-off jobs and snippets; use esbuild, Terser, SWC or Lightning CSS in your build.
Minification versus compression
They are different layers and they multiply.
- Minification changes the source text at build time. It is permanent and lossless with respect to behaviour.
- Compression (gzip, Brotli, Zstandard) is applied by the server at transfer time and undone by the browser. The stored file is unchanged.
A 100 KB stylesheet might minify to 70 KB, then gzip to 18 KB, then Brotli to 15 KB. Minifying first genuinely helps compression too, because removing noise raises the density of the patterns the compressor exploits.
Brotli at quality 11 typically beats gzip by 15–20% on text and is supported by every current browser over HTTPS. If you are only serving gzip, enabling Brotli is usually a one-line server change and one of the cheapest performance wins available. See the file size converter to put the numbers in context.
Why bytes matter for Core Web Vitals
Render-blocking CSS and synchronous JavaScript sit directly on the critical path. Every byte delays First Contentful Paint and, usually, Largest Contentful Paint. JavaScript is worse than its transfer size suggests because it must also be parsed, compiled and executed — roughly 1 ms per kilobyte on a mid-range phone, before your code does anything.
Sensible budgets for a content page:
- Critical CSS inlined: under 14 KB, so it fits in the first round trip.
- Total CSS: under 100 KB minified.
- JavaScript on first load: under 150 KB compressed.
- Total page weight: under 1 MB, against a real-world median above 2 MB.
Minification is the easiest of these to achieve and the smallest lever. Removing an unused framework beats minifying a used one every time.
When minification breaks things
Four cases to watch for, all of them real:
- Missing semicolons in JavaScript. Code that relies on automatic semicolon insertion can change meaning when line breaks disappear. Always terminate statements explicitly.
- Meaningful whitespace in HTML. Inline elements are separated by real space characters; collapsing them can visually join words. Content inside
<pre>and<textarea>must never be touched. - Conditional comments. Legacy IE conditional comments look like comments and are not. This tool preserves them.
- CSS hacks. Old browser hacks depend on deliberately malformed syntax that a minifier may normalise away. If you still ship them, verify after minifying.
Always keep the unminified source in version control and generate the minified output during the build. Never edit minified files directly, and ship source maps so production errors remain debuggable.
Frequently Asked Questions
What is minification?
Removing characters a program does not need — comments, indentation, line breaks and extra whitespace — so the file transfers faster while behaving identically.
Does minification break my code?
Correct minification is behaviour-preserving. Problems arise with code that relies on automatic semicolon insertion, meaningful whitespace in HTML, or deliberately malformed CSS hacks.
Should I minify if my server already uses gzip?
Yes. They compound: minifying first removes noise and lets the compressor work on denser input, so the compressed result is smaller than compressing unminified source.
What is the difference between minification and obfuscation?
Minification optimises for size and keeps behaviour readable in principle. Obfuscation deliberately makes code hard to understand, often at the cost of larger files and slower execution.
Can I un-minify code?
You can reformat it, which is what the beautify mode does for CSS and JSON. You cannot recover original variable names or comments unless a source map is available.
How much will minification save?
Typically 20–35% for CSS, 30–60% for JavaScript with a full minifier, and 10–20% for HTML. This tool's conservative approach lands at the lower end of each range.
Should I minify by hand or in a build step?
Always in a build step. Manual minification means the deployed file diverges from your source, which is a maintenance trap. Keep the readable version in version control.
Sources & further reading
- web.dev: Text compression — how minification and compression combine on the wire
- MDN: Minification — definition and relationship to bundling
- HTTP Archive: State of JavaScript — real-world payload sizes to benchmark your budget against
- RFC 7932: Brotli — the compression format that supersedes gzip for text