Minification vs Compression

What each one does

• Minification changes the file. The result is what is stored and served, and it is what appears in your source map.
• Compression changes only the transfer. The server encodes, the browser decodes, and the file on disk is unchanged.
• Minification is a build step. Compression is a server or CDN setting.
• Minification is irreversible in practice — original names and comments are gone. Compression is exactly reversible.

Why compression usually wins

Source code is extremely repetitive: the same keywords, property names and patterns over and over. Compression algorithms are built to exploit exactly that, so they typically remove the large majority of a text file's bytes. Minification removes whitespace, comments and — for JavaScript — shortens identifiers, but much of that whitespace was highly compressible anyway, so some of its saving overlaps with what compression would have achieved regardless. Brotli generally beats gzip on text and is supported by every current browser; serving Brotli with a gzip fallback is the standard arrangement.

Why minification is still worth doing

The savings stack, and the compressed size of a minified file is smaller than the compressed size of an unminified one. There are also gains compression cannot give you: shorter identifiers reduce the bytes the JavaScript parser must read, dead-code elimination removes work entirely rather than encoding it efficiently, and a smaller file decompresses faster on low-end devices. For JavaScript in particular, parse time matters as well as transfer.

Getting the order right

Minify at build time, compress at serve time. Compressing during the build and storing pre-compressed files is a valid optimisation — it lets the server use a slower, higher-quality compression setting once rather than on every request — but the sequence is always minify first, then compress. Compressing before minifying achieves nothing, since the minifier cannot read compressed bytes.

What not to minify

HTML gains little, because it is already mostly tags that compress extremely well, and aggressive HTML minification risks breaking pre, textarea and inline script content. JSON APIs should not be pretty-printed in the first place, so there is nothing to remove. Images and fonts are already compressed — running gzip over a PNG or a WOFF2 makes them slightly larger, which is why servers should be configured to compress text types only.

Frequently asked questions

• JavaScript Minifier Strip comments and whitespace from JavaScript safely. In your browser
• CSS Minifier Compress CSS by removing whitespace and comments. In your browser
• HTML Minifier Shrink HTML by removing whitespace and comments. In your browser
• JSON Minifier Strip whitespace from JSON and see the size saved. In your browser
• HTTP Header Checker Inspect the response headers and status a URL returns. Server-side

• How to Check HTTP Redirects Trace a URL through every hop to its destination, and tell a permanent redirect from a temporary one.
• JSON Validator vs JSON Formatter Both parse your JSON. They differ in what they give you back and which one to reach for.