^{minification benchmarks}

What's the best JavaScript minifier?

This project benchmarks the following minifiers:

Benchmarks last updated on Apr 30, 2026.

🙋‍♂️ Why?

1. To help you pick a minifier that fits your needs
2. To promote JS minifiers and document their performances
3. To encourage healthy competition and improvement amongst minifiers

👟 Methodology

• Each minifier is executed in its own process with a 10s timeout
• Artifact integrity is verified by a test before and after minification
• Each minifier is minimally configured (sourcemaps & comments disabled), comparing out-of-the-box experience
• Minifier upgrade PRs are automated via WhiteSource Renovate
• Benchmarks are updated on every PR via GitHub Actions
• The raw benchmark data is available in /packages/data/data/data.json

⏱ Metrics

Ranking

For each benchmark, minifiers are ranked by a score that reflects the best balance of trade-offs.

The score combines minzipped size and minification time, with size weighted more heavily by default (85% size, 15% time) since it's usually the top priority. If a minifier is unusually slow, the weights shift toward time using a logistic sigmoid function, up to a 50/50 split. This avoids harsh cutoffs while still penalizing extreme slowness.

Both size and time are scaled using min-max normalization so they can be compared fairly. The result is a context-aware score that helps surface the best overall choice—but make sure to check each column directly if size or speed matters more to you.

Minified size

Size of the minified output.

Minzipped size

Size of the minified output with Gzip compression.

For minifiers, this measures how compressable the output is.

For users, this measures network transfer size, which is usually the metric that matters most.

Time

How long minification took (average of 5 runs). Each time is annotated with a multiplier relative to the fastest minifier.

📋 Results

⚔️ Minifier showdown

Three... two... one... compress! Welcome to the Minification Grand Prix, where every byte fights for survival and every millisecond screams for mercy. The field was full of specialists: the old-school size hunters, the new-school speed demons, and a few hybrid contenders that managed to do both without tripping over semicolons. Let’s unpack the race.

Best minifier

@swc/core takes the trophy. It didn’t always have the single smallest number on every tiny package, but it won the big, meaningful rounds and kept a gorgeous balance between squeeze and speed. On large bundles it frequently produced the smallest (or nearly the smallest) gzipped output—echarts, antd, three—and did it hundreds to thousands of times faster than the pure size champion. Where uglify-js eked out the very last kilobyte, @swc/core typically matched that compression within a hair while finishing in a fraction of the time. For teams shipping big bundles or running minification in CI, that trade-off is decisive: tiny transfer wins, without the lava-slow wait.

Honorable mentions

• uglify-js — The pure size monarch. Five rounds with the absolute smallest gzip size. If absolute minimal bytes are your religion and you can tolerate multi-second runs on huge artifacts, keep uglify on the altar. Example: “victory” was squeezed to 157.44 KB, but it cost several seconds where swc did almost the same in a few hundred milliseconds.
• oxc-minify — The surprise giant-slayer. Won the largest TypeScript bundle and showed up fast and tight on several large inputs. Excellent when you want near-top compression on very large codebases and still care about build speed.
• @cminify/cminify-linux-x64 — The speed demon for big files. Consistently among the fastest, often completing massive bundles in a few dozen milliseconds, but with noticeably worse gzip sizes compared to the top compressors.
• @tdewolff/minify — Blink-and-you-miss-it speed on smaller packages with solid compression. Great for quick local runs or tiny CI steps.
• terser — A reliable all-rounder that still commands wins on some classic libs (notably jquery). Good balance for many conventional use cases.

Eliminated

• babel-minify — Failed during the "react" run with: "Failed to find JSON start: [baseline-browser-mapping] The data in this module is over two months old. To ensure accurate Baseline data, please update: npm i baseline-browser-mapping@latest -D". Disqualified from the leaderboard.
• tedivm/jshrink — Crashed during "d3" minification: "RuntimeException: Unclosed regex pattern at position: 289075". Crashed and eliminated.

Closing remarks

This was a contest of trade-offs, not moral superiority. Uglify-js is the go-to if you worship minimal bytes and can wait. @swc/core is the pragmatic champion: near-best compression, far better speed, and strong results on the largest, hardest artifacts. oxc-minify and cminify earned their stripes as specialist tools—one squeezing large TypeScript bundles, the other blitzing them at the cost of extra bytes.

Remember: these results only measure gzipped size and minification time. Developer experience, compatibility, and correctness matter in the real world too. Pick the tool that matches your pipeline: if you ship huge bundles and hate long CI times, start with @swc/core. If every kilobyte must be wrung out, give uglify-js a spin. And if you want instant local feedback, try the speed demons and see how they fit. Until next race—keep your bytes tight and your builds fast.

Sponsors