JavaScript minification reduces file size by removing unnecessary characters while preserving functionality. Here's how it works, what tools to use, and common misconceptions.
What minification does
Before:
``javascript
// Calculate the factorial of n
function factorial(n) {
if (n <= 1) {
return 1;
}
return n * factorial(n - 1);
}
const result = factorial(10);
console.log("Result:", result);
`
After (with Terser, compress + mangle):
<code>javascript
<p>function e(n){return n<=1?1:n*e(n-1)}const t=e(10);console.log("Result:",t);</p>
</code>
Same functionality. Dramatically smaller. For a JavaScript minifier, paste your code and get the minified version instantly.
What Terser does (the dominant minifier)
Terser has two main stages:
Compress: Transforms the code semantically:
- Removes dead code
- Inlines constants
- Collapses simple functions
- Simplifies conditional expressions: if (x === true) { return 1; } else { return 0; }
→ return x?1:0
Mangle: Renames identifiers:
- factorial
→ e (single character) - result
→ t - Local variable names become single characters
Both are enabled by default. You can use compress without mangle if you need readable (but optimized) output.
Size reduction
Typical JavaScript file size reductions:
| Transformation | Savings |
|----------------|---------|
| Whitespace + comment removal only | ~15–20% |
| + constant folding and dead code removal | ~20–30% |
| + identifier mangling | ~30–50% |
| + gzip/Brotli compression | ~70–80% total vs. original |
Large libraries like React see bigger absolute savings: react.development.js (~3MB) → react.production.min.js (~42KB) → ~8KB with Brotli.
Terser in your project
Via bundler (recommended):
Vite and webpack use Terser (or esbuild) automatically in production builds — no configuration needed for most projects.
<code>bash
<p>vite build # Uses esbuild for minification by default</p>
<p>npm run build # In CRA (Create React App) — uses Terser</p>
</code>
Terser CLI:
<code>bash
<p>npm install -g terser</p>
<p>terser input.js -o output.min.js --compress --mangle</p>
<p>terser input.js -o output.min.js -c -m # shorthand</p>
<p>terser input.js -o output.min.js -c -m --source-map "url='output.min.js.map'"</p>
</code>
Terser API (Node.js):
`javascript
import { minify } from 'terser';
const result = await minify(code, {
compress: {
dead_code: true,
drop_console: true, // Remove console.log() calls
pure_funcs: ['console.info', 'console.debug'] // Treat as pure (removable)
},
mangle: {
toplevel: false, // Don't mangle top-level names (safer for globals)
keep_classnames: true
},
format: {
comments: false // Remove all comments
}
});
console.log(result.code);
`
esbuild (10–100x faster than Terser):
<code>bash
<p>npm install -g esbuild</p>
<p>esbuild input.js --minify --outfile=output.min.js</p>
<p>esbuild input.js --bundle --minify --target=es2020 --outfile=bundle.min.js</p>
</code>
esbuild is written in Go and is dramatically faster than Terser — often the better choice for CI/CD pipelines. Slightly less aggressive compression than Terser, but the speed difference makes it better for large codebases.
What minification does NOT do
It's not obfuscation. Minified code can be formatted back to readable code with a beautifier. Mangled variable names lose their meaning, but the logic remains visible.
It doesn't improve runtime performance. The browser parses and compiles JavaScript regardless of whitespace. Minification reduces download time, not execution time.
It's not tree shaking. Tree shaking (dead code elimination at the module level) is done by bundlers (Rollup, webpack, esbuild) during the bundling phase, before minification. Minification's dead code removal only applies within a function or scope, not across module boundaries.
It doesn't eliminate unnecessary dependencies. A minified lodash bundle still contains all of lodash. Use tree shaking and specific imports instead.
Source maps
Minified code is difficult to debug. Source maps link the minified output back to the original source:
<code>bash
<p>terser input.js -o output.min.js --source-map "url='output.min.js.map'"</p>
<h1>Creates output.min.js and output.min.js.map</h1>
</code>
The browser's DevTools use the source map to show the original code when debugging — even though the browser is executing the minified version.
In production: serve source maps from a private URL or behind authentication if you don't want to expose source code publicly.
Beautifying minified code
If you need to read minified JavaScript (third-party library, legacy code), a beautifier adds formatting back:
`bash
Prettier
prettier --write output.min.js
js-beautify CLI
npm install -g js-beautify
js-beautify output.min.js
`
In VS Code: paste minified JS into a .js file and press Shift+Alt+F`.
Note: beautification restores formatting but not the original variable names — those are permanently gone when code is mangled.
Performance: when minification matters most
Minification has the biggest impact when:
- Users are on mobile with limited bandwidth
- You have large JS bundles (SPA frameworks)
- Your CDN serves content globally to high-latency regions
- Users are first-time visitors (no cached files)
For a 100KB JavaScript file → 60KB minified → 15KB with Brotli, the difference is significant on a slow 3G connection (8× faster to download) but negligible on fiber.
The combination of minification + Brotli + HTTP/2 multiplexing + code splitting is the full performance picture for JavaScript delivery.
Minification is a solved problem — modern bundlers handle it automatically. The only time you need to think about it explicitly is when minifying files outside of a bundler or when tuning Terser options for advanced use cases like removing console.log calls or preserving specific identifiers.
Originally published at https://snappytools.app/javascript-minifier-beautifier/