Not every installed package ships to production. See which ones do.
A vulnerability scanner lists packages your deployed app never loads.
Drop in a package-lock.json and see the lockfile evidence
for which dependencies actually reach production versus which are
build- or test-only — entirely in your browser.
Drag a package-lock.json here, or
— or paste its contents below —
Don't have one handy? — a small lockfile with production, transitive-production, and build-only packages, so you can see the report shape before using your own.
What this is and isn't
- Everything runs in your browser. The lockfile you drop or paste is never uploaded — there is no server here to send it to.
- "Build-only" is a lockfile classification, not a security verdict. A build-only package can still run on the machine that builds your app, and dynamic imports or other runtime behavior need human review — this cannot prove absence, only report what the lockfile states.
-
This reads
package-lock.jsonv2/v3 (npm 7+) only. It does not inspect yarn or pnpm lockfiles. - Only anonymous, aggregate usage counts (for example "a report was generated") may be recorded locally — never the lockfile contents or package names.
Common questions
Does "build-only" mean this package is safe to ignore?
No. Build-only means the lockfile shows every install location for that package as dev-only — absent from your deployed application artifact. It can still be exposed on the machine that runs your build, and a scanner flagging it there is doing its job. Use this report to prioritize review, not to dismiss a finding.
Why does a package I didn't install show up?
Most entries are transitive: a dependency your direct dependencies pulled in. The Evidence column says why each row was classified the way it was — "declared by the application" for packages in your own package.json, or "at least one install location is on a production path" for a transitive dependency that a production package needs.
Does this replace my vulnerability scanner?
No. This tool never checks packages against any advisory database — it only reads what your lockfile already states about where each package installs. Pair it with your existing scanner's findings to see which flagged packages are actually reachable in production.
Is my lockfile uploaded anywhere?
No. Parsing happens with JavaScript running in your own browser tab. This page makes no network request with your file's contents — there is nothing to intercept because nothing is sent. Only anonymous, aggregate usage counts like "a report was generated" may be recorded locally, with an opt-out below.
Is there a command-line version?
Yes — the same classification logic ships as a local Python CLI (npm_deployment_evidence.py) in this tool's repository, for CI pipelines or scripted use. See the README for its usage.
Does this work with yarn.lock or pnpm-lock.yaml?
No. This reads package-lock.json v2 or v3 only — the format npm 7 and later writes. Drop or paste a yarn.lock or pnpm-lock.yaml and you'll get an error asking for package-lock.json instead, because the two formats don't share a structure this tool can read. If your project uses npm but the lockfile predates v2, delete it and run npm install again to regenerate a version this report can parse.
Which npm vulnerabilities actually reach production? · This tool vs. npm audit