npm Bundle Size Checker — Gzip & Minified

It sends the package name (and, in package.json mode, the dependency names and version ranges you pasted) to four public services: the npm registry, esm.sh which bundles the package, jsDelivr which serves the package's published README, and GitHub's public API for the stars, issues and commit counts — but only when the package points at a GitHub repository. Never to any server run by this site. A package name isn't private data the way pasted source code or a password is, so this is the one tool on the site that makes real third-party network requests, the same way this site's cURL Command Builder does when you press "Send request." Nothing is sent on page load.

Because every way of naming a package was already a complete request, and making you confirm it twice served nothing. A check now starts when you click one of the popular packages, pick a suggestion, press Enter, choose or drop a package.json file, or simply stop typing. The typed case has one guard: it only runs once the name you typed matches a package the registry search has already confirmed exists, so a half-typed "reac" never fires a real bundle request and never flashes a "no such package" error at you mid-word. Pressing Enter deliberately skips that guard, so an outright typo still gets a real error message rather than silence.

They describe how a package can be imported, read from its own package.json. "ESM only" means it ships an ES module entry — the `import`/`export` syntax, whose imports and exports are fixed at parse time, so a bundler can see exactly which exports you use and delete the rest. That is what makes tree-shaking possible. "CommonJS only" means it ships just the older Node format, `require()` and `module.exports`, whose exports are ordinary runtime property assignments rather than declarations — a bundler usually cannot prove which ones you left unused, so it includes the whole module. That is why importing one function from a large CommonJS package often costs you the entire package. "ESM + CommonJS" is a dual package that ships both, normally through an `exports` map with separate `import` and `require` conditions: bundlers take the ESM build and tree-shake it, and plain `require()` still works. "No entry point declared" means neither was found, which usually indicates a types-only package, one meant to be imported only by a deep subpath, or a publishing mistake.

The `sideEffects` field in a package.json is a promise about whether merely importing a module from the package does anything observable on its own — patching a global, injecting CSS, installing a polyfill. `"sideEffects": false` (or an empty array) says it does not, and that promise is what lets a bundler delete a module you imported but never actually used. A `true` value, or a list of specific files, says some modules do have side effects, so a bundler keeps those even when nothing appears to use them. "Unspecified" means the package simply does not have the field at all — which is not a claim that it is dirty, it is the absence of a claim either way. That is why it is shown in neutral grey rather than as a warning: the field is optional and predates most published packages, so a perfectly clean package may just never have added it. The practical consequence is only that bundlers must assume the worst and tree-shake more conservatively than they would with an explicit `false`.

It measures the cost of importing only the exports you list — e.g. entering "debounce" for lodash — using esm.sh's tree-shaking support instead of the whole package. This mirrors what your own bundler would ship if you wrote `import { debounce } from 'lodash'` and tree-shaking worked correctly. Three outcomes are all useful answers: it shrinks a lot (the package separates its exports cleanly), it barely changes (the package routes everything through one shared internal module, so there is genuinely nothing left to shake — a property of the package, not a limitation of this tool), or it fails outright with a clear error, which is what a CommonJS-only package does. In a real build that last case happens quietly and you get the whole package anyway.

It is the README published inside the package's own tarball for the exact version being measured — not the one currently on the repository's default branch, which may be further ahead. The npm registry only carries READMEs on the full multi-megabyte document listing every version of a package at once, which this tool deliberately never downloads, so the file is fetched from the jsDelivr CDN instead. Its relative image and link paths are rewritten to point at the package's repository so they still resolve here, the Markdown is sanitized before rendering, and every link in it opens in a new tab.

Two reasons. First, they come from GitHub's public API, which is the only repository host with a public, key-free, browser-callable API — a package that publishes its source on GitLab, Bitbucket or its own git server still gets a repository link, just no stats. Second, GitHub allows 60 anonymous API calls an hour per IP address, and this site has no backend and therefore no API token to raise that. A long session of checking packages can genuinely run out, in which case the tool says so and everything else on the page keeps working.

Because that is honestly what the number is. GitHub's repository API returns a single `open_issues_count` that counts open pull requests as issues, and separating them needs a call to the much more heavily rate-limited search API. Rather than quietly present a combined figure as an issue count, it is labelled for what it actually measures; click it to see the real breakdown on GitHub.

It should be close but won't always match exactly. This tool fetches the package bundled into a single file by esm.sh, re-minifies it with Terser, then gzips the result with your browser's native compression — a fixed, consistent pipeline applied identically to every package. bundlephobia uses its own bundler and minifier on its own servers, so the two can differ by a few percent depending on how each bundler handles a given package's exports.

Yes — add `?q=` and the package name to this page's address, e.g. `/bundle-size-checker/?q=react` or `/bundle-size-checker/?q=lodash@4`. The tool fills in the field and checks it as soon as the page loads, which makes it usable as a browser search keyword or a bookmarklet. The page's canonical URL stays the plain `/bundle-size-checker/` either way, so these links are a convenience for you rather than separate pages in a search index.

Each dependency needs its own registry lookup, its own bundle fetch from esm.sh, and its own minify+gzip pass — real work, not a lookup table. To avoid hammering two free public services at once, at most five dependencies are checked in parallel, so a large package.json can take a noticeable amount of time. Cancel stops queuing new dependencies; ones already in flight still finish, and everything not yet started is marked cancelled rather than left stuck.

Yes — select any package name in the dependencies or devDependencies table, or in a single package's own dependency breakdown, and it opens as a full single-package result — README, module format, project health, major-version chart, the lot. From a package.json table it is pinned to the version that row resolved, so you see exactly what your project would install rather than whatever is latest today. Your package.json, its tables and its totals are all kept, so the "package.json" tab brings them straight back — it is a detour into one row, not a reset.

Each direct dependency is measured as its own standalone bundle, the same way the package itself is measured. If two dependencies both depend on a third package, that shared package's code is counted once in each of their standalone sizes — a real bundler would only ship it once, deduplicated, so the breakdown is a guide to relative weight, not an exact accounting that sums to the headline number.

A live badge has to be an image rendered fresh on every request by a server, so it always reflects the current published version — this site has no backend to do that. The "Copyable summary" line gives you a plain-text snapshot of what you just measured instead; it won't update itself if the package is republished, which a generated badge would.

This tool resolves the range against every version actually published to the registry the same way `npm install` would, favoring the highest matching non-prerelease version. It supports the ranges that show up in practice — exact versions, `^`/`~`, x-ranges like "1.2.x", plain comparators, and hyphen ranges — but an unusual combination it can't parse falls back to reporting an error rather than silently guessing, so check the resolved version shown in the results if the range was more than a plain caret or tilde.

It finds the latest non-prerelease release of each earlier major version (up to six, most recent first), measures each one the same way as the package you just checked, and shows the byte difference from that result. It's a real fetch-and-bundle per major version shown, not an estimate, which is the single largest part of the request count for one check.

They answer different questions. dependencies ship to whoever installs your package or app; devDependencies are only needed to build or test it and never reach an end user's bundle. Summing them into one "total" would overstate what your app actually ships, so checking "Include devDependencies" adds a second table and total instead of mixing the two lists together.