b2KIT

Import Cost Estimator

Check the size impact of npm package imports with minified and gzipped size estimates.

Tested tool guide Tested browser tools Checked August 16, 2026

What Import Cost Estimator does and how it behaves

Paste JavaScript import statements to inspect the estimated code weight associated with their npm packages. The tool reports separate minified and gzipped figures, helping distinguish compact bundle size from compressed transfer size. It is intended for quick dependency comparisons, not exact production measurements. The most common mistake is treating the gzipped estimate as the package's installed size or as a guarantee of what users will download. A finished bundle can differ because its package versions, retained exports, shared dependencies, and chunk boundaries are build-specific.

How the result is produced

1

Import recognition

The input consists of JavaScript import declarations referring to npm packages. For each recognized package specifier, the estimator presents minified and gzipped size estimates. A package-root specifier and an exposed package subpath can represent different entry points, so compare results only for the exact import forms you intend to use. The pasted declarations are processed in the browser and are not uploaded.

2

Two size views

The minified figure estimates a compact representation of the imported JavaScript. The gzipped figure estimates its compressed representation and is the more relevant number when comparing gzip transfer weight. Their difference comes from compression, not additional feature removal. Both remain estimates because a complete build may discard exports, combine modules, split chunks, or share dependencies among several imports.

Good uses

  • Screening a proposed npm dependency during code review before adding it to a browser bundle.
  • Comparing the displayed size impact of two npm packages that provide the same client-side feature.
  • Checking whether a documented package subpath appears smaller than importing the package root before testing a production build.

Limits and checks

  • Confirm that the package release behind the estimate matches the version in your lockfile. Package contents and export maps can change between releases.
  • Do not assume a named import automatically costs only one exported function. Actual tree shaking depends on package structure, side effects, module format, and build configuration.
  • Gzipped size is neither runtime memory use nor a universal network measurement. Brotli, caching, source maps, chunk overhead, and previously downloaded shared code can change delivery costs.

Common questions

Does the gzipped estimate equal the bytes my users will download?

No. It is an estimate associated with the import, not an observation from your production deployment. The final download can change with the selected package version, bundler transformations, tree shaking, shared modules, source maps, chunk boundaries, and server compression. Build the application in production mode and inspect its emitted assets when exact transfer bytes matter.

Can this tool prove that a named or subpath import produces a smaller bundle?

Not by itself. It can show the estimates available for import forms it recognizes, but it cannot establish exactly what your bundler will retain. Verify the result with a production bundle report, especially when the package mixes module formats, declares side effects, re-exports other modules, or contributes dependencies already present elsewhere in the application.

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