Bundle Size Calculator
Estimate package sizes and analyze bundle impact — updates as you type
About this ToolHow it works, benefits & use casesTap to collapse
Before you reach for bundlephobia, this calculator gives you a fast, offline ballpark of what a list of npm packages adds to your bundle. Type package names one per line — with or without a version suffix like lodash@4 — and it looks each one up in a built-in table of common library sizes, totals the minified and gzipped weight, and breaks every package down with a low/medium/high/critical impact tag. It scores your total gzipped size against a 3G performance budget (excellent under 50KB, critical over 200KB) and writes targeted recommendations: swap moment for date-fns, import lodash-es by function, enable tree-shaking for UI kits, or add code splitting. Unknown packages fall back to a rough heuristic. The whole analysis recomputes as you type and produces a copyable text summary. Sizes are estimates, so it complements — not replaces — real tools like webpack-bundle-analyzer.
How to Use
- 1Type one package name per line in the "Package list" box — version suffixes like react@18 are accepted, and # lines are ignored.
- 2Or click "Load example" to populate a sample list of common dependencies.
- 3Watch the totals, performance-budget verdict, and per-package breakdown update live as you edit.
- 4Read each package's minified and gzipped size plus its LOW/MEDIUM/HIGH/CRITICAL impact badge.
- 5Copy or download the text summary, which includes the per-package breakdown and the recommendations.
Key Benefits
- Instant offline size estimates for a list of packages — no waiting on a network lookup
- Separate minified and gzipped totals plus a per-package breakdown
- Impact tags (low / medium / high / critical) flag the heaviest dependencies
- 3G performance-budget verdict from excellent (<50KB) to critical (>200KB gzipped)
- Targeted advice — e.g. replace moment with date-fns, tree-shake UI libraries
- Recomputes live as you type, with a copyable text summary to share
- Accepts version suffixes and comment lines so you can paste real dependency lists
Common Use Cases
- Sanity-checking whether adding a library will blow your performance budget
- Comparing the relative weight of alternative libraries before choosing one
- Spotting the heaviest dependencies in an existing project to target for trimming
- Producing a quick shareable size summary for a code review or RFC
- Teaching the cost of bundle bloat with concrete minified vs gzipped numbers
One package name per line — e.g. react, lodash@4, axios
Was this tool helpful?
Share Your Experience
Help others discover this tool!
Related tools
- Bundle Analyzer VisualizerPaste a bundle file list to get a visual size treemap, gzip/brotli estimates, performance-budget pass/fail checks, and a build-vs-build diff of what grew or shrank
- File Size FormatterConvert any file size across decimal (KB/MB/GB) and binary (KiB/MiB/GiB) units side by side, with exact byte counts and a download-time estimator across 56k → fiber connection speeds
- Image Optimization CalculatorPlan responsive images — recommended breakpoints with ×1/×2 DPR, ready-to-paste srcset/picture/Next.js <Image> markup, per-format byte estimates, and total savings vs shipping the full-size original
- Intersection Observer GeneratorGenerate IntersectionObserver code from a use-case picker (reveal, lazy-load, infinite scroll, scroll-spy, sticky, video autoplay) with a live trigger-zone diagram and vanilla/React/Vue output
- Performance Budget CalculatorCalculate and track performance budgets for web apps
- Speculation Rules GeneratorBuild the modern speculationrules script for instant navigations — prerender/prefetch, document rules & eagerness
They are estimates from a built-in table of common package sizes, not live measurements. Real-world size depends heavily on tree-shaking, code-splitting, and which parts of a package you import. For precise numbers use bundlephobia.com or webpack-bundle-analyzer — this tool is for fast, offline ballpark comparisons.
If a package is not recognised exactly, the tool tries the unscoped name and partial matches. If it still cannot find it, it falls back to a rough heuristic based on the name length, so the estimate for obscure packages is approximate.

