b2KIT

Bundle Size Analyzer

Estimate JavaScript bundle sizes with tree-shaking simulation and package size comparison.

Tested tool guide Tested browser tools Checked August 16, 2026

What Bundle Size Analyzer does and how it behaves

Bundle Size Analyzer frames dependency choice as a comparison of estimated JavaScript bundle sizes. It models how excluding unused exports could change a package's contribution, then lets competing packages be judged on the same size-oriented question. The result is useful before committing to a dependency or import pattern. The important surprise is that a tree-shaken estimate is conditional: production output also depends on package structure, side effects, bundler configuration, code splitting, and the exact package version.

How the result is produced

1

Package comparison

The comparison treats each package as a candidate source of bundle code and presents estimated sizes for judging their relative cost. This answers whether one dependency is plausibly lighter than another, not whether the smaller package is functionally equivalent. Differences in features, transitive dependencies, versions, and import patterns still matter when interpreting the comparison.

2

Tree-shaking simulation

The simulation models the reduction possible when exports that are not used can be excluded from a bundle. Tree shaking is most reliable when module relationships can be determined statically and modules do not require discarded code for side effects. The simulated remainder is therefore a scenario estimate, not a promise about every bundler or build configuration.

Good uses

  • Compare two libraries that solve the same development task before adding either one to an application with a bundle-size budget.
  • Estimate whether importing only selected exports could materially reduce the shipped portion of a utility, component, or data-processing package.
  • Investigate why a package's full published size is not necessarily the same as the amount expected to remain in an optimized application bundle.

Limits and checks

  • Do not substitute the estimate for measurement of a production build. Plugins, transpilation targets, dependency deduplication, minification, and bundler settings can change the final bytes.
  • Confirm which package version and size unit the comparison represents. Package contents change between releases, while raw, minified, and compressed byte counts answer different performance questions.
  • A smaller total does not necessarily mean a faster initial page load. Code splitting, lazy loading, caching, parsing cost, and whether the dependency enters the initial chunk affect the observed result.

Common questions

Can this predict the exact size of my production bundle?

No. It provides an estimate for comparing package and tree-shaking scenarios. Exact output requires building the real application with its selected versions, imports, target environments, bundler configuration, and optimization settings. Use the analyzer to narrow choices, then verify the preferred choice against the generated production assets.

Does using a named import guarantee that the other exports disappear?

No. A named import can give a bundler a statically identifiable dependency, but elimination still depends on the package's module form, re-exports, side effects, and build configuration. Some unused code may remain because executing the module is observable or because the dependency structure cannot be safely reduced.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools