PyPI Provenance Check vs. checking each package on PyPI by hand
Opening one package's PyPI page and checking its provenance information works fine for a single dependency you're curious about. It does not scale to a requirements.txt or pyproject.toml with dozens of packages, each needing the right pinned version's page found among however many releases that project has, 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 pypi.org, find the release you actually installed, and look for provenance information. For a single package that's a minute of clicking. The problem is a real dependency set is rarely one package — it's a requirements file 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 pypi.org yourself | This checker |
|---|---|---|
| Whether one specific package's page shows provenance information. | 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 release that matches your pin — ==, >=, a range, or no pin at all (meaning whatever resolves latest) — among however many releases that project has published. | Requires remembering which pin syntax means what while clicking through a project's release history, for every package. | Resolved against PyPI's own metadata API the same way every time, for every package in the file. |
| Doing the same lookup consistently across a requirements file with dozens of direct and transitive dependencies. | The same several clicks repeated dozens of times, 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 set again after a requirements file 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 pypi.org doesn't already publish — it's reading the same PEP 740 integrity API 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 file 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 PyPI's own public API.
Common questions
Can't I just look up each package on pypi.org myself?
For one package, yes -- open its PyPI page, find the release you actually installed, and check its provenance information. What doesn't scale is doing that for every package in a requirements.txt or pyproject.toml: each one needs its own page found, the specific pinned (or latest) version's release located among however many releases 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 release version easy to get wrong by hand?
A requirements.txt pins versions in several different ways -- an exact ==, a floor >=, a range, or no pin at all (meaning whatever resolves as latest at install time) -- and a popular package can have dozens or hundreds of published releases. Finding the one release page that matches what your pin actually resolves to, 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 which pin syntax means what while clicking through release history.
Why is it easy to lose track partway through a long dependency list?
A typical project's requirements file runs to dozens of direct and transitive dependencies. Checking each one by hand means repeating the same several clicks -- find the package, find the right release, look for provenance information, note the result -- dozens of times in a row, 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 file 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 PyPI facts. What a manual pass through pypi.org 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 PyPI page and checking its provenance information before trusting it. It names no competing product or company. This tool makes only read-only requests to PyPI's own public API, the same facts a manual page visit would show.
Already know about PyPA's own verification tool? Read why not just pypi-attestations verify.