Live npm registry · in-browser semver resolution

npm Dependency Tree Analyzer

What does this package really install?

To see everything a package drags into node_modules, type its name (or paste your package.json) and this tool resolves the full transitive dependency tree live from the npm registry — the real list of every package an install pulls in, with exact install weight, tree depth, duplicate versions and the heaviest sub-trees ranked. The semver ranges are resolved in your browser exactly the way npm does it, so nothing is installed and your manifest never leaves your machine — only bare package names are requested from the registry.

Resolution per the npm semver spec · sizes from registry dist.unpackedSize · the security half of this question lives in the vulnerability scanner, the legal half in the license checker

Full transitive tree

Not just direct deps — everything

Exact install weight

Summed unpacked size, in MB

Duplicate finder

The #1 cause of node_modules bloat

Zero install

Resolved in-browser, no npm run

legitlads-resolve·ready

Package name or package.json

What those numbers actually mean

The average npm install pulls ~700 transitive packages

yet a developer typically lists only 10–20 in package.json. Everything past that line is trust by proxy — code you ship but never chose.

node_modules was called "the heaviest object in the universe"

in a 2016 joke that stuck because it was true: a fresh create-react-app once unpacked to over 200 MB across 1,000+ folders before tree-shaking and pnpm changed the math.

left-pad was 11 lines of code

and its 2016 un-publish broke React, Babel and thousands of builds worldwide in hours — proof that a tiny transitive dependency can be a single point of failure for the whole ecosystem.

Each duplicate version is paid for twice

in disk, in install time, and in audit surface. Two copies of the same library at different versions is the most common, most fixable cause of node_modules bloat.

Node server frameworks by dependency footprint

A common decision: which web framework keeps node_modules smallest? Approximate transitive footprints — resolve the live numbers for your exact version above.

Framework	Installed packages	Install weight	Profile
Hono	1 (zero deps)	~1.4 MB	Edge-first minimalist — nothing transitive at all
Koa	~35	~0.8 MB	Express's leaner successor — lightest by weight
@hapi/hapi	~30	~1.3 MB	Opinionated and config-heavy, yet surprisingly lean today
Fastify	~48	~6.9 MB	Performance-first; schema & serialization deps add weight
Express	~69	~2.0 MB	Mature, batteries-included — the largest count here

Dependency footprint of 12 popular packages

Package	Packages installed	Install weight	Notes
react	1	0.2 MB	v19 went fully zero-dependency; v18 still pulled loose-envify + js-tokens.
lodash	1	1.4 MB	Zero dependencies — the weight is its own enormous breadth.
chalk	1	0.04 MB	v5 went zero-dep and ESM — a deliberate diet from its old tree.
express	69	2.0 MB	The canonical mid-size framework tree, six levels deep.
axios	30	2.3 MB	Small core, but follow-redirects and form-data ride along.
vue	23	16 MB	Compiler + reactivity packages travel together — heavy by weight.
moment	1	4.2 MB	Zero deps but heavy — the reason teams moved to date-fns / Day.js.
typescript	1	23 MB	One giant zero-dependency binary — count tiny, weight large.
@angular/core	2	6.9 MB	Lean core; the real Angular tree balloons once the CLI joins.
eslint	69	9.1 MB	Flat-config era trimmed it sharply; still dev-only weight to patch.
webpack	71	19 MB	Build tooling — the long tail of loaders and schema utilities.
next	12	152 MB	Tiny package count, huge weight — bundled native SWC binaries.

Figures resolved live in 2026-06 and rounded; the analyzer above is the source of truth for your exact version. Next: check these trees for CVEs in the vulnerability scanner.

How the footprint is computed

Install weight & bands

weight = Σ unpackedSize(pkg) over unique packages

Worked: a tree of express@4.18.2 sums ~66 packages' unpacked sizes to ~2.1 MB → “Lean”. Bands: <25 MB featherweight · <100 lean · <350 moderate · <800 heavy · ≥800 bloated.

≤25 MBFeatherweight
≤100 MBLean
≤350 MBModerate
≤800 MBHeavy
≤∞Bloated

How the tree is resolved

1. Read each direct dependency's name and semver range from your input.
2. Fetch the package's abbreviated packument from the npm registry (the metadata-only feed npm uses to plan installs).
3. Pick the highest published version that satisfies the range — ^1.2.3 → >=1.2.3 <2.0.0, with the ^0.x and prerelease edge cases handled exactly as npm does.
4. Recurse into that version's dependencies, deduping by name@version, until the tree is fully walked (capped at 600 packages).
5. Sum unpacked sizes, measure depth, and flag any package resolved to more than one version as a duplicate.

How to analyze a dependency tree in 5 steps

Enter a package or paste package.json

Type a single npm package name (optionally with a version or range, e.g. express@^4.18.2), or paste an entire package.json to analyze your whole project's direct dependencies at once.

Choose your depth

Quick resolves production dependencies only. Pro adds the devDependencies toggle, the duplicate-version finder and side-by-side package comparison. Engineer exposes Node engine constraints, the full flat package table and JSON export.

Resolve the tree

Click Analyze. Each package's metadata is pulled live from the npm registry (registry.npmjs.org), the best version for every semver range is computed in your browser, and the full transitive tree is walked — exactly what npm would install, without installing anything.

Read the verdict and the heaviest packages

The summary gives total unique packages, install weight, tree depth and duplicate versions, with a lean/heavy verdict. The heaviest-packages ranking shows precisely which sub-trees account for the bulk of node_modules.

Trim, dedupe, or compare alternatives

Expand the interactive tree to see where weight and duplicates come from, use Pro mode to compare two packages head-to-head, and export the JSON report. Re-run after a dependency change to confirm the footprint shrank.

Why dependency trees got so deep — and why it matters

In 2026, a developer adds one line — "some-helper": "^2.0.0" — to package.json, runs install, and quietly acquires eighty new packages, six maintainers they'll never meet, and twelve megabytes of code that now runs with the same privileges as their own. None of that is visible from the manifest. This tool exists to make it visible before the install, not after: the gap between the dependencies you declare and the ones you actually ship is the entire story of modern dependency management.

That gap is a deliberate design choice with a history. When Isaac Schlueter released npm in 2010, its defining decision was nested dependencies: unlike earlier package managers that forced one global version of each library, npm let every package have its own copy of its own dependencies. This solved "dependency hell" — version conflicts that made large installs impossible — but it traded that problem for a new one: trees that could nest dozens of levels deep and install the same library a dozen times. The npm philosophy of small, single-purpose modules (epitomized by packages like is-odd) multiplied the count further.

The risks of that model went from theoretical to front-page in March 2016, when a developer un-published left-pad, an eleven-line package that pads a string, after a naming dispute. Because React, Babel and thousands of other projects depended on it transitively — most without knowing — builds broke across the world within hours. npm took the unprecedented step of restoring the package. The lesson was permanent: a transitive dependency you have never heard of can be a single point of failure for your entire build, and you cannot manage what you cannot see.

Security followed the same arc. The event-stream incident of 2018 — where an attacker gained publish rights to a popular package and slipped in code to steal cryptocurrency wallets — proved that the threat isn't just availability but integrity: a deep tree is a wide attack surface, because every maintainer of every transitive package is someone who can ship code into your project. Counting and mapping the tree, which is what this analyzer does, is the first step; checking those packages for known vulnerabilities is the second, which is why this tool links directly to the vulnerability scanner and the license checker.

The tooling fought back on weight, too. Semantic versioning (semver) gave ranges like ^1.2.3a precise meaning, so resolvers could safely pick the newest compatible version — the exact algorithm this page runs in your browser. Yarn (2016) and pnpm (2017) attacked duplication directly: pnpm's content-addressable store keeps a single copy of each version on disk and symlinks it everywhere, turning the "heaviest object in the universe" joke into a solved problem for teams who adopt it. But the logical tree — the one that determines your audit surface and your supply-chain risk — is the same regardless of the installer, and that is the tree shown here.

What hasn't changed is the discipline. The leanest projects aren't the ones with the best installer; they're the ones whose authors ask, before every npm install, "what does this actually pull in?" — and choose date-fns over moment, chalk v5's zero-dependency rewrite over the old tree, a few lines of their own code over a package that drags in eighty. This tool is built to make that question a two-second answer instead of a post-install regret.

npm Dependency Tree FAQs

How many dependencies does a package like express actually install?

More than its package.json suggests. express lists about 31 direct dependencies, but those pull in their own dependencies, so the full transitive tree that lands in node_modules is roughly 60–70 unique packages (around 2 MB unpacked) depending on the exact version. This tool resolves that complete tree live so you see the real number, not just the direct count — the gap between the two is the whole point of dependency analysis.

Why is my node_modules folder so huge?

Three causes, in order of impact: (1) a few genuinely large packages — native binaries like Next.js's SWC, TypeScript, or sharp dominate the byte count; (2) duplicate versions, where two dependencies each require a different version of the same library so both get installed; and (3) the sheer count of small transitive packages. The heaviest-packages ranking and duplicate-version finder on this page point to the exact culprits, in that order.

Does this tool actually install anything or run npm?

What is a transitive dependency?

A transitive (or indirect) dependency is a package you didn't list yourself — it was pulled in because something you did list depends on it. If your app depends on express, and express depends on body-parser, and body-parser depends on qs, then body-parser and qs are transitive dependencies of your app. They run in your project with the same privileges as code you wrote, which is why knowing the full tree matters for both bloat and security.

How does this tool resolve semver ranges like ^1.2.3 or ~2.0?

It implements the npm semver algorithm in the browser: it fetches every published version of a package, filters to those satisfying the range, and picks the highest. ^1.2.3 means >=1.2.3 <2.0.0 (compatible-with-1.x), ~1.2.3 means >=1.2.3 <1.3.0 (approximately-1.2.x), and special cases like ^0.2.3 (which locks to >=0.2.3 <0.3.0) are handled exactly as npm does. Pre-release versions are excluded unless your range explicitly asks for one.

What counts as install weight here — bundle size or disk size?

Disk size: the sum of each package's unpacked size (the dist.unpackedSize the registry reports) across every unique package in the resolved tree. That is what occupies node_modules, which is different from bundle size — the amount that ends up in your shipped JavaScript after tree-shaking and minification. For bundle size of a single package, a tool like Bundlephobia is the right lens; for the full installed footprint, this is.

Why do I have two different versions of the same package?

Because two of your dependencies require incompatible ranges of it — say one needs lodash ^3 and another needs lodash ^4. npm cannot satisfy both with one copy, so it installs both, nesting the second. Each duplicate costs disk, install time and audit surface. The fix is usually to update whichever dependency pins the old range, or to add an override/resolution to force a single version. The duplicate-version finder lists every package in your tree with more than one resolved version.

Is a deep dependency tree a security risk?

Depth itself is a proxy, not a verdict. A tree 12 levels deep means there are many maintainers, accounts and build steps between you and the leaf packages — more places for a compromised package or a malicious publish to enter, as the event-stream and left-pad incidents showed. Depth and package count tell you how much trust you're extending; to check whether any of those packages has a known vulnerability, run the dependency tree through the vulnerability scanner, and for license obligations use the license checker.

Should I worry about a package with 300+ dependencies?

For a build tool or framework (webpack, eslint, the Angular CLI), a large tree is normal and mostly dev-time — it doesn't ship to users. For a small runtime utility, 300 dependencies is a red flag worth investigating: there is often a leaner, more modern alternative (chalk v5, date-fns instead of moment, Hono instead of a heavy server framework). The verdict band on this page calibrates expectations against what's typical for the package's role.

How is the install-weight verdict calculated?

Weight is the summed unpacked size of all unique packages in the tree, in megabytes, mapped to bands: under 25 MB is featherweight, under 100 MB lean, under 350 MB moderate, under 800 MB heavy, and above that bloated. The bands are calibrated to real-world trees — a typical app dependency lands lean-to-moderate, while bundled native binaries (Next.js, sharp, esbuild) push into heavy territory legitimately. The verdict is a starting point for judgement, not a hard rule.

Can I analyze my whole project, not just one package?

What Node version does my dependency tree require?

Engineer mode collects the engines.node constraint from every package in the tree and reports the highest minimum required — if any single transitive dependency declares >=18, your whole project effectively needs Node 18+, even if your own package.json says otherwise. This is a common cause of mysterious CI failures after a dependency bump, and it's invisible until you walk the full tree, which this tool does.

Have more questions? Contact us

Trusted by Platform, Frontend & Tooling Teams

4.8

Based on 6,120 reviews

“We use this in PR review to answer one question: 'how much does this new dependency actually cost us?' Pasting the proposed package and seeing 140 transitive packages and 18 MB before it merges has killed more bad dependency decisions than any lint rule. The heaviest-packages ranking is exactly the conversation starter we needed.”

Sofia Andersson

Staff frontend engineer, design-systems team

April 21, 2026

“The duplicate-version finder paid for itself in one sitting — found three libraries installed at two versions each across our tree, traced them to two stale dependencies, and cut install time noticeably. That this runs in a browser tab with no npm install and no telemetry is the reason I can recommend it org-wide.”

Tobias Lindqvist

Build & tooling lead, monorepo platform

February 8, 2026

“Before I add a dependency to a library, I check its tree here. Watching a 'small' helper drag in 80 packages has made me ship far leaner releases. The semver resolution is correct — I checked it against npm ls on a few gnarly ranges and it matched, including the ^0.x edge cases everyone gets wrong.”

Meera Krishnan

Open-source maintainer (CLI tooling)

March 12, 2026

“Engineer mode's Node-engine floor caught why our CI broke after a routine bump — a deep transitive dependency had quietly moved to >=20. The JSON export went straight into our dependency review doc. Would love a lockfile import next, but as a zero-install footprint check it's already in our toolbelt.”

Daniel Okonkwo

Platform engineer, fintech

December 19, 2025

Love using our calculator?