npm Provenance Check vs. checking each package on npmjs.com by hand
Opening one package's npmjs.com page and checking its provenance badge works fine for a single dependency you're curious about. It does not scale to a package-lock.json with dozens or hundreds of packages, each needing the right resolved version's page found, checked, and the result written down — which is what this free, no-upload checker does in one pass from a pasted file.
Where checking it yourself stops being enough
Anyone curious about one specific dependency already does this: open its page on npmjs.com, switch to the version you actually have installed, and look for the provenance badge. For a single package that's a minute of clicking. The problem is a real dependency tree is rarely one package — it's a package-lock.json with dozens of direct and transitive entries, and the manual version of this check does not get easier per-package as the list grows.
| What you're trying to confirm | Checking npmjs.com yourself | This checker |
|---|---|---|
| Whether one specific package's page shows a provenance badge. | Works. This is the one case a single manual lookup reliably handles. | Also handles it, in the same pass as every other package in your file. |
| Finding the exact version your lockfile resolved — not just whatever npmjs.com shows by default — among however many versions that project has published. | Requires switching the version dropdown to match your lockfile's resolved version, for every package. | Reads the resolved version straight out of the pasted package-lock.json, the same way every time. |
| Doing the same lookup consistently across a lockfile with dozens or hundreds of direct and transitive dependencies. | The same several clicks repeated over and over, with no running tally except what you remember or type into a separate note; easy to drop a row partway through. | Every package in the pasted file, checked the same mechanical way, with nothing skipped. |
| Producing a list of just the packages still missing an attestation, in a form you can hand to a teammate or feed to a migration tracker. | Nothing beyond whatever you wrote down yourself while clicking through pages. | The CLI emits exactly that list as JSON in one run. |
Re-checking the whole dependency tree again after package-lock.json changes. | The full manual pass again, one package at a time. | One paste, the whole file, every time. |
A quick look at one package's page is still the fastest way to answer a one-off question, and this
checker isn't reading anything npmjs.com doesn't already publish — it's reading the same
dist.attestations.provenance registry field a manual check would eventually reach, just
resolving every package in a pasted file automatically instead of leaving the lookup to be repeated by
hand across however many dependencies the lockfile has.
This tool needs no account and no sign-in: your file is parsed entirely in your browser, and only package names and versions ever leave it, in read-only requests to the public npm registry.
Common questions
Can't I just look up each package on npmjs.com myself?
For one package, yes -- open its npmjs.com page, find the version you actually installed, and check whether that version's page shows a provenance badge. What doesn't scale is doing that for every package in a package-lock.json: each one needs its own page found, the specific resolved version located among however many versions that project has published, and the result written down somewhere before you move to the next package. This tool resolves and checks every package in a pasted file in one pass.
Why is matching the right resolved version easy to get wrong by hand?
A package-lock.json records the exact resolved version npm installed for every direct and transitive dependency, but npmjs.com's package page shows the badge for whichever version you land on -- by default the latest, not necessarily the one your lockfile pins. Finding the one version page that matches what your lockfile actually resolved, for every package in the file, is the kind of lookup that is reliable when a tool does it the same way every time and error-prone when it depends on remembering to change the version dropdown before reading the badge.
Why is it easy to lose track partway through a long dependency list?
A typical project's package-lock.json runs to dozens or hundreds of direct and transitive dependencies. Checking each one by hand means repeating the same several clicks -- find the package, switch to the resolved version, look for the provenance badge, note the result -- over and over, with no running tally except what you remember or type into a separate note. It is the same kind of repetitive, easy-to-drop-a-row task a mechanical pass through a pasted lockfile does exactly the same way every time.
What do I get from a manual check that this tool doesn't produce?
Nothing extra -- both read the same registry facts. What a manual pass through npmjs.com doesn't produce on its own is a single list of which packages in your file lack an attestation, in a form you can hand to a teammate, paste into a migration tracker, or feed to another script. This tool's CLI emits that list as JSON in one run; a manual check produces only whatever you wrote down yourself.
Is this page making a live comparison against a tool or company?
No. This page describes a manual habit any maintainer or reviewer already has -- opening a package's npmjs.com page and checking its provenance badge before trusting it. It names no competing product or company. This tool makes only read-only requests to the public npm registry, the same facts a manual page visit would show.
Already know about npm audit signatures? Read why not just npm audit signatures.