Is webpack-bundle-analyzer Accurate? A 2.3x Size Gap

I ran webpack-bundle-analyzer 5.4.0 and source-map-explorer 2.5.3 on the same webpack 5.111 production build, and they disagreed on date-fns by 2.3x: 44,313 bytes in the analyzer versus 19,196 bytes in source-map-explorer. Lodash matched within 176 bytes, so the gap was not random; it came from webpack's module concatenation, which forces the analyzer to estimate sizes inside the merged module.

Short answer: use source-map-explorer when you need to know which package actually owns the bytes in a minified, scope-hoisted bundle. Keep webpack-bundle-analyzer for chunk-level views, gzip numbers and quick treemaps, and read its numbers inside a "(concatenated)" box as estimates. Speed is not the deciding factor here: source-map-explorer took a median 224 ms for JSON output and the analyzer CLI took 313 ms. No affiliate links in this post.

What I tested

• Machine: 8 vCPU Intel Xeon / 15 GB RAM Linux cloud box, Node 20.19.2, tested 5 Oct 2026 (about 23:36 to 23:42 IST). Shared box; runs interleaved after one warmup each.
• Fixture: /workspace/bench-sme-wba/ with one entry, 120 small feature modules that each import format and addDays from date-fns 4.4.0, plus a default lodash 4.18.1 import. webpack 5.111.1 + webpack-cli 7.2.3, mode: 'production', devtool: 'source-map'. Output: main.js 148,569 B and main.js.map 930,179 B; stats.json 3.78 MB.
• Tools: source-map-explorer 2.5.3 reading main.js + its map; webpack-bundle-analyzer 5.4.0 reading stats.json + dist/, both as CLIs. I also built once with BundleAnalyzerPlugin in static mode.
• Timing: seven interleaved CLI wall clocks per variant via process.hrtime around the full command; five interleaved webpack builds per build variant.
• Findings: source-map-explorer JSON median 224.3 ms, HTML 243.8 ms. webpack-bundle-analyzer JSON median 312.6 ms, static HTML 327.3 ms. Build medians: plain 3.49 s, --json stats 3.13 s, with plugin 3.34 s (all inside run-to-run noise on this box).
• One surprise: source-map-explorer 2.5.3 exited 1 on its default run ("generated column Infinity on line 2"). It only worked with --no-border-checks.
• Not tested: Vite or Rollup output, multi-chunk apps with dynamic imports, devtool variants other than source-map, the analyzer's server mode, Windows/macOS.

Why do the two tools report different sizes?

Module group	source-map-explorer bytes	Analyzer parsed bytes	Gap
lodash	70,312	70,136	about equal
date-fns (37 files)	19,196	44,313	analyzer 2.3x higher
my src (121 files)	58,258	33,840	analyzer 42% lower
whole bundle	148,569	148,569	same total

Lodash is a single CommonJS module, so webpack kept it as its own module and both tools saw the same bytes. Date-fns and my source files were scope-hoisted into one module the analyzer labels "index.js + 157 modules (concatenated)". Its JSON report marks all 158 inner entries with inaccurateSizes: true. The numbers fit a proportional split: date-fns is 102,305 of the module's 180,547 source bytes, and 57% of the 78,237 minified bytes is about 44,330, within 20 bytes of what the analyzer showed. Date-fns source is verbose (JSDoc, long names), so it got credit for bytes that minification had already removed. source-map-explorer walks the source map byte by byte, so it does not need to guess.

For the bundler side of this, see the Rspack vs webpack post and the webpack 5.111 ESM output post.

Can you make webpack-bundle-analyzer accurate?

Yes, at a cost. I rebuilt with optimization.concatenateModules: false. The analyzer then reported date-fns at 22,174 bytes and flagged zero inaccurate entries, close to source-map-explorer's 19,966 bytes for the same build. But the bundle grew from 148,569 to 163,525 bytes (+10%), because scope hoisting is a real size win. Do this in a throwaway "analyze" build, not in the build you ship.

source-map-explorer also has a --gzip flag. With it (plus --no-border-checks), it reported a 31,346-byte gzip total, the same total the analyzer showed, and put date-fns at 9,008 gzip bytes.

Which bundle analyzer should you use?

Situation	My pick
"Which npm package is making my bundle big?" in a production webpack build	source-map-explorer
You need chunk-level treemaps, gzip sizes per chunk, or a CI HTML artifact from the webpack build	webpack-bundle-analyzer (plugin or CLI)
Your bundler is not webpack (Vite, Rollup, esbuild) and emits source maps	source-map-explorer (analyzer needs webpack stats)
You want exact per-module numbers from the analyzer	Separate analyze build with concatenateModules: false
No source maps in production and you will not turn them on	webpack-bundle-analyzer

Bottom line: on one webpack 5 build, the two tools agreed on the total and on lodash, but date-fns was 44 KB in one and 19 KB in the other. Who should not bother with source-map-explorer: teams whose big wins are whole chunks or duplicate vendor copies, which the analyzer shows well. To shrink what these tools find, the terser vs esbuild/swc minify post and the knip vs depcheck post cover minifiers and unused dependencies; for a CI byte budget, see size-limit vs bundlesize.

How this was made: I generated the fixture, built it with webpack, ran both analyzers on the ShopperCove test box, timed interleaved runs and kept the JSON; the write-up was drafted with AI help and checked against that output.

Sources

• 01github.com/danvk/source-map-explorer
• 02npmjs.com/package/source-map-explorer
• 03github.com/webpack/webpack-bundle-analyzer
• 04npmjs.com/package/webpack-bundle-analyzer
• 05webpack.js.org/configuration/optimization/
• 06webpack.js.org/plugins/module-concatenation-plugin/

Related

• 01shoppercove.com/blog/rolldown-vs-rollup
• 02shoppercove.com/blog/madge-vs-dependency-cruiser
• 03shoppercove.com/blog/vite-8-3-2-renderbuilturl-bundled-dev-sourcemaps-october-2026