Popular:
npm Bundle Size Checker
Enter a package name and see its minified and gzipped size, download time estimates, dependency count, and whether it supports tree-shaking.
Tip: add @version for a specific release, e.g. react@17
// check npm package size before you install
Check the minified and gzipped size of any npm package before installing. See download time estimates, dependency count, and compare alternatives side by side. Free, no sign-up.
Enter a package name and see its minified and gzipped size, download time estimates, dependency count, and whether it supports tree-shaking.
Tip: add @version for a specific release, e.g. react@17
Type any npm package — simple (lodash), scoped (@tanstack/react-query), or versioned (react@17) — and click Check Size or press Enter.
The card shows minified size, gzipped size (what users download), download time estimates at four network speeds, and whether the package is tree-shakeable.
Click + Compare to add the package to the comparison panel. Add more packages for a side-by-side bar chart — useful for picking between moment, date-fns, and dayjs.
npm Package Size uses the Bundlephobia API to fetch real bundle size data for any package on the npm registry. It shows the minified size, gzipped size (what users actually download), download time estimates, dependency count, and tree-shakeability — so you can make informed install decisions without running npm locally.
The minified size is what the JavaScript file weighs after stripping whitespace, comments, and shortening variable names — but before any network compression. The gzipped size is after applying gzip compression, which all modern web servers do automatically. Your users download the gzipped version; the browser decompresses it before executing. The gzipped size is typically 60–80% smaller than minified, and it's the number that matters for network performance.
A tree-shakeable package uses ES module syntax (export function foo() {}) and declares "sideEffects": false in its package.json. This lets your bundler (webpack, Rollup, Vite) include only the functions you actually import, discarding the rest. The size shown here is for the full package — if you only import one function from a tree-shakeable package, your actual bundle contribution will be much smaller. Non-tree-shakeable packages (CommonJS) are always fully included.
The estimates use the gzipped size divided by typical effective throughput for each connection type: 2G (30 Kbps effective), 3G (400 Kbps), 4G (2 Mbps), and cable (8 Mbps). These match the Chrome DevTools network throttle presets. Real download times depend on server location, latency, HTTP/2 multiplexing, and other factors — the estimates are useful for relative comparisons, not precise predictions.
Yes. Add @version to the package name — for example react@17.0.2 or lodash@4. You can use an exact version, a major version, or any semver range that resolves to a single version. This is useful for comparing how bundle size changed between versions, or for evaluating whether upgrading a dependency would affect your bundle.
General guidelines: utility functions should be under 5 KB gzipped (most individual lodash-es functions are 1–3 KB); UI component libraries under 30 KB gzipped; frameworks under 50 KB. moment.js at 77 KB gzipped is a well-known example of a package that many teams replace with lighter alternatives. Context matters — a 100 KB package may be fine for an internal tool but unacceptable for a page targeting 2G users.
Bundlephobia reports the size of the whole package bundled standalone. Your actual bundle contribution depends on tree-shaking (if only some exports are used), code-splitting, duplicate dependency deduplication, and minifier optimisations across your entire codebase. For tree-shakeable packages, your actual cost is often far lower than the total package size. Use a bundle analyser like webpack-bundle-analyzer to see the real contribution in your specific project.
Every npm package you add to a front-end project has a bundle size cost that users must pay. Checking that cost before running npm install is a simple habit that prevents the gradual bundle bloat that slows down web applications over time. This tool fetches real minified and gzipped sizes from the Bundlephobia API, so you can see exactly what you're committing to without installing the package locally.
The most important figure is the gzipped size. Modern web servers compress JavaScript with gzip or Brotli before sending it over the network. The browser downloads the compressed version and decompresses it locally — a fast operation on modern hardware. When evaluating whether a package is "too large," compare the gzipped size against your performance budget. A package that appears large in its minified form may be quite reasonable once compressed.
The size shown is a worst-case figure assuming you import the entire package. For tree-shakeable packages — those that use ES module syntax and declare sideEffects: false — the actual cost in your bundle depends on how much you import. Using import { format } from 'date-fns' pulls in roughly 2 KB of the 30 KB date-fns package. Always check tree-shakeability when evaluating a package, and use selective imports wherever possible.
Several categories of heavy packages have well-maintained lightweight alternatives. For dates: day.js (2 KB gzipped) vs moment.js (77 KB). For HTTP: native fetch (0 KB) or ky (4 KB) vs axios (13 KB). For utilities: native JavaScript or individual lodash-es imports vs lodash (70 KB). For animations: framer-motion has a smaller "m" component export for motion elements. The comparison feature in this tool makes it easy to evaluate the size difference between alternatives before committing.