Paste your package metadata above and select Check package to see a provenance, install-script, maintainer, and release-risk card.
About the npm provenance badge checker
The npm provenance badge checker turns the metadata for a public npm package into a short risk card so you can make a faster call before you add or approve a dependency. A package can look fine by name and still ship without build provenance, run an install script that executes arbitrary code on install, declare no source repository, or rest on a single maintainer account. This tool surfaces those signals so a person can decide what to do before the dependency lands.
Paste the metadata you get from npm view package --json, select Check package, and the tool reads the resolved version manifest and reports a row per check: build provenance, registry signature, integrity hash, install lifecycle scripts, repository link, maintainer count, deprecation, and release age. Each row carries a status, a severity, plain-language evidence, and a review prompt, and you can download a findings CSV or copy a markdown risk card. Everything runs in your browser. The metadata you paste, the package name, and the maintainer names are never uploaded or stored.
How to use
- Run npm view your-package --json (or copy the registry metadata response) to get the package metadata JSON.
- Paste the metadata into the box. A synthetic sample package with a postinstall script, no provenance, and a single maintainer is loaded by default so you can see how it works.
- Select Check package to read the resolved version manifest and run the provenance and supply-chain checks.
- Review the table: each row shows the check, a status, a severity, what it means, and a review prompt.
- Select Download findings CSV or Copy risk card to keep a record before you add or approve the dependency.
Worked examples
postinstall script flagged High
A package that defines a preinstall, install, or postinstall script runs code on your machine at install time, so the script is flagged for a read before you install.
no build provenance flagged Review
When a publish carries no provenance attestation there is no signed link from the release back to its source build, so the tool asks for extra source review before you trust the artifact.
single maintainer flagged Low
A package maintained by one account is a higher account-takeover and bus-factor risk, so it is surfaced to weigh against how critical the dependency is.
Frequently asked questions
- What package metadata should I paste?
- Paste the JSON from npm view your-package --json, which returns the package document including dist-tags, versions, maintainers, and publish times. You can also paste a single version manifest. The tool resolves the latest version from dist-tags when a full package document is pasted, and reads the fields it needs from there.
- Why does the tool run on pasted metadata instead of looking the package up for me?
- Keeping it paste-only means nothing about the package you are reviewing leaves your browser, the checks are deterministic, and the tool does not depend on registry uptime or cross-origin access. Live package-name lookup is a planned follow-up; the first version reads metadata you paste.
- What is build provenance and why does it matter?
- Build provenance is a signed attestation that links a published package to the source commit and build that produced it. When it is present you can verify the artifact came from the expected source build rather than a hand-uploaded tarball. When it is missing there is no such link, so the tool recommends extra source review before you trust the release.
- Why are install scripts flagged so highly?
- preinstall, install, and postinstall scripts run automatically when the package is installed, with the permissions of the install. That is a common path for supply-chain attacks, so the tool flags any install lifecycle script for a read, and you can install with scripts disabled if you want to review them first.
- Is the package metadata uploaded anywhere?
- No. The parsing and all of the checks run in your browser. The metadata you paste, the package name, and the maintainer names are never sent to a server or saved. Download the findings CSV or copy the risk card before you close the tab.
- Does a clean card mean the package is safe?
- No. The checks are heuristics over the metadata fields, not a guarantee. A package with provenance, a signature, a source link, and multiple maintainers is a better starting point, but you should still review the source and the changelog before you add or approve a dependency.
Use this again tomorrow
Save this page so it's one tap away when you need a quick result.
Ready for a quick Daily Challenge?
Play Daily Challenge on sts.games