Chris Collins

Tools · dev

Dependency tree analyser

Paste mvn dependency:tree, gradle dependencies, go mod graph or cargo tree output, or drop a package-lock.json, pnpm-lock.yaml, yarn.lock or Cargo.lock, and see the tree, why each package is there, which version won each conflict and why, duplicates, depth and weight, licences, and (if you ask) known vulnerabilities from OSV.dev.

Added · updated 28 October 2026

Works with

How to use it

Every build tool will print its dependency tree, but the printout doesn’t answer the questions you actually have: why is this jar here, which version won and why, what’s in there twice, and what would go if I dropped this dependency. Paste the output or drop the lockfile here and it does. It opens on a real Maven example; the Examples menu has Gradle, Go, Cargo, npm and pnpm ones, all real output from small projects built with public libraries.

What it reads

Maven

mvn dependency:tree, with or without [INFO] prefixes, and -Dverbose, which adds the entries Maven dropped: omitted for duplicate, omitted for conflict with 3.33.0, version managed from, scope updated from. Multi-module builds become one section per module.

Gradle

gradle dependencies (or :app:dependencies): every configuration as its own section, 1.11 → 1.16.0 upgrades, (*) repeats, (c) constraints, (n) declared-only configurations, FAILED, project :core, {strictly 1.7.36} and substitutions.

Go

go mod graph, best with go.mod dropped alongside (marks // indirect, lists replace). go.mod and go.sum on their own work too.

Rust

cargo tree (Unicode, --charset ascii or --prefix depth), including the [build-dependencies] and [dev-dependencies] sections, and Cargo.lock.

JavaScript

package-lock.json (v1, v2, v3), pnpm-lock.yaml (v5, v6, v9), yarn.lock (classic v1 and berry), and npm ls --all as text or --json. Drop package.json with a yarn.lock to say which dependencies are dev ones; yarn doesn’t record that.

How to use it

  1. Paste the output into the box, or drop files on it (several at once is fine: a lockfile and its package.json, or go mod graph output and go.mod). It analyses as you paste.

  2. Pick a configuration (Gradle) or module (Maven) if there are several, and untick scopes you don’t care about: Maven’s compile/runtime/provided/test, Cargo’s normal/build/dev, npm’s prod/dev/optional/peer. Every view follows the filter.

  3. Tree is collapsible. Each package’s dependencies are opened where it first appears; later appearances are marked. Type in the box to highlight a package and open the paths to it.

  4. Why is it here? lists every path from your project to a package, shortest first, and names the direct dependencies that bring it in. Click any name anywhere to jump here.

  5. Conflicts & duplicates shows each package that was asked for in more than one version, who asked for what, what the build tool chose, and why — by that tool’s own rule:

    • Maven: nearest wins. The version closest to the root is used; at equal depth, the first one declared. Versions aren’t compared, so an older one can beat a newer one. Those cases are flagged newer version lost — the usual cause of NoSuchMethodError at run time. Run -Dverbose to see them; the plain tree hides the losers.

    • Gradle: highest wins, per configuration, unless a strict/forced version, rejection or rule says otherwise (also flagged).

    • Go: minimal version selection. The highest version any module in the graph requires — no newer. Major versions are different module paths, so they never collide.

    • Cargo: SemVer-compatible unification. Requirements that are compatible share one version; incompatible ones (a new major, or a new minor below 1.0) are built side by side. That’s why rand_core 0.5 and 0.6 can both be in a build.

    • npm, pnpm, yarn: nested copies. When no single version fits every range, more than one is installed. When one version would fit every range, it says so — a dedupe would merge them.

  6. Size & depth gives counts, a depth histogram, the deepest chain, the most depended-on packages, and for each direct dependency how much it brings in and how much only it brings in — what you’d lose by removing it. Licences are counted when the input has them (package-lock.json).

  7. Packages is a sortable, filterable table (name, version, scope, licence, depth, used by), with a CSV download. Open in SBOM viewer sends the same packages, with the dependency graph, to the SBOM viewer as CycloneDX — for licence classes and a CycloneDX file. The other way, the SBOM viewer opens the Maven, npm, Go or Cargo packages of an SBOM here.

  8. Vulnerabilities checks the resolved versions against OSV.dev when you press the button, and lists advisories with severity, CVE ids and the first fixed version.

To test the version ranges you see here against candidate versions, use the version ranges and SemVer tool; duplicate entries link straight to it with the ranges filled in.

The page works in any current browser. A share link carries the chosen example, tab and the "why" package — not what you pasted.

Privacy

What you paste or drop is parsed in this page and never uploaded. The last input is kept in your browser’s local storage so it’s still there when you come back; Clear removes it.

The one exception is the Vulnerabilities tab, and only when you press its button: it sends the list of package names, versions and the ecosystem (Maven, Go, crates.io or npm) to api.osv.dev, Google’s Open Source Vulnerabilities service, then fetches the advisories it returns. Nothing else goes — not the file, the tree or your project’s name. The tab shows the exact request before you send it.

The built-in examples were generated on 2026-10-28 with Maven 3.9.9, Gradle 8.14.1, Go 1.23.3, cargo 1.99.0, npm 11.20.0 and pnpm 10.18.3 from small projects using public dependencies; hashes and local paths were removed.

Runs entirely in your browser — network requests go only to the services named on this page.