Skip to content
100% local

Webpack stats analyzer

Find which packages and modules take up the most space in a webpack build.

Input

Webpack stats analyzer

Generate a stats.json from webpack (`webpack --json > stats.json`, or with `stats: { modules: true }` in your config) and paste it here to see exactly which packages and modules are inflating your bundle. This is the fastest way to answer "why is my build so big" without installing a bundle-analyzer plugin or rebuilding with special flags — the report reads the JSON you already have.

Group the report by node_modules package to see which dependency costs the most, by folder to see which part of your own source tree is heaviest, or leave it ungrouped to inspect individual modules one by one. The rows-to-show option caps a long report to the biggest offenders; percent share puts each row's size in context against the total; and if your stats.json carries a compressed-size field per module (gzipSize or sizeGzip), turning on the compressed-size column shows both numbers side by side. Filtering by an entry point or chunk name narrows everything to one bundle, which is useful once an app has more than one output file.

The tool also flags packages that show up at more than one node_modules install path — a common sign that two dependencies pin incompatible versions of the same library and webpack ends up shipping both copies. Those rows are marked in the output so they're easy to spot even in a long report. Choose table output for a readable report or CSV for pasting into a spreadsheet when you're tracking bundle size over time.

Everything runs in your browser: the stats.json is parsed and analyzed locally and is never uploaded anywhere, so it's safe to use with a proprietary codebase. Copy the result, download it as a .txt file, or send it straight to another tool's input to keep working.

FAQ

How do I generate a stats.json?
Run your webpack build with `webpack --json > stats.json`, or add `stats: { modules: true }` to your webpack config so the compiler prints module data. The tool needs a top-level "modules" array to work.
What does grouping by package show that grouping by folder does not?
Grouping by package collapses every file under node_modules/react (for example) into one row, so you can see a dependency's total footprint. Grouping by folder instead reports your own source directories, which is more useful for finding an oversized feature in your own code.
Why does it warn about "duplicate" packages?
When two dependencies each require a different version of the same library, npm or yarn can nest a second copy inside node_modules instead of deduplicating it. This tool spots a package name that appears at more than one install path and flags it, since removing the duplicate is often an easy way to shrink a bundle.
Does it show real gzip sizes if my stats.json does not include them?
No. Compressed size is only shown when your stats.json already carries a gzipSize or sizeGzip field per module — the tool never compresses anything itself, since that would mean re-running a build step. Without that field, the compressed-size column shows a dash.
Is my stats.json uploaded anywhere?
No. Parsing and analysis run entirely in your browser — the file never leaves your device.