Free online tool
Lockfile Drift Checker: Check Whether Your Lockfile Matches package.json
Paste your package.json file and your pnpm-lock.yaml or package-lock.json file to check whether the lockfile still matches what your project declares. The Lockfile Drift Checker lists every package that is missing from the lockfile, every locked version that no longer satisfies its declared range, and every stale entry left behind after a removal, entirely in your browser, with nothing uploaded. Use it before pushing, so a frozen-lockfile install on Vercel or in CI does not fail with ERR_PNPM_OUTDATED_LOCKFILE after the code has already left your machine.
Quick answer
Quick answer
Paste package.json and your pnpm-lock.yaml or package-lock.json to check whether the lockfile still matches what the project declares, entirely in your browser. In the example, heic2any is declared as ^0.0.4 but has no lockfile entry, so the verdict is FAIL: a frozen-lockfile install would fail with ERR_PNPM_OUTDATED_LOCKFILE. Run pnpm install locally and commit the updated lockfile to fix it.
Open the interactive Lockfile Drift Checker
The interactive tool loads in the page. Enable JavaScript to enter data, process content, and download results.
Example check: a missing lockfile entry
A project declares heic2any in package.json, but the lockfile has no entry for it: the same drift that stops a frozen-lockfile install with ERR_PNPM_OUTDATED_LOCKFILE.
| Package | heic2any |
|---|---|
| Declared | ^0.0.4 |
| Locked | No entry in the lockfile |
| Verdict | FAIL: frozen-lockfile install would fail |
About this tool
About the Lockfile Drift Checker
Paste your package.json file and your pnpm-lock.yaml or package-lock.json file to check whether the lockfile still matches what your project declares. The Lockfile Drift Checker lists every package that is missing from the lockfile, every locked version that no longer satisfies its declared range, and every stale entry left behind after a removal, entirely in your browser, with nothing uploaded. Use it before pushing, so a frozen-lockfile install on Vercel or in CI does not fail with ERR_PNPM_OUTDATED_LOCKFILE after the code has already left your machine.
Detailed guide
How to get useful results from Lockfile Drift Checker
What lockfile drift is, and why deploys fail on it
A lockfile records the exact version installed for every dependency your project declares. Drift appears when package.json changes but the lockfile is not regenerated to match: a dependency is added, a version range is edited, or a package is removed, and the committed lockfile still describes the old state. The project works on the machine where the change was made, because the local install updated the lockfile there, but the committed lockfile tells a different story.
Deploy platforms such as Vercel typically install with the frozen-lockfile option, which refuses to change the lockfile during the build. When the lockfile is out of date, pnpm stops the build with ERR_PNPM_OUTDATED_LOCKFILE. The error does not name the package that drifted, so the fix starts with finding it. Checking the two files against each other before pushing turns a failed deploy into a one-command local fix.
How the checker reads pnpm and npm lockfiles
For pnpm, the checker reads the packages and snapshots sections of pnpm-lock.yaml, in both the v8 layout (keys with a leading slash) and the v9 layout (bare name@version keys), including scoped package names such as @scope/name. For npm, it reads the packages section of package-lock.json for lockfileVersion 2 and 3, and the dependencies tree for lockfileVersion 1. Nested node_modules entries inside another package are ignored, so only the project's own locked versions are compared.
Declared ranges come from dependencies, devDependencies, peerDependencies, and optionalDependencies in package.json. Each locked version is tested against its declared range with caret, tilde, exact, comparator, wildcard, hyphen, and union ranges. Ranges the checker cannot evaluate from the two files alone, such as workspace: references, file: paths, and git URLs, are reported as cannot verify automatically and are left out of the verdict instead of risking a false failure.
Fixing drift without guessing
A FAIL names the exact package and shows the declared range beside the locked version, or shows that no lockfile entry exists at all. Run pnpm install for a pnpm project or npm install for an npm project in the project folder: the package manager regenerates the lockfile from package.json. Commit the updated lockfile together with the package.json change that caused the drift, so the two files always travel as a pair.
Stale entries, packages that are locked but no longer declared, are shown as warnings only. They do not fail a frozen-lockfile install, and a fresh install pass removes them. Re-run the checker after fixing to confirm a PASS, and make the check part of the routine before any push that touches dependencies. The sample inputs on the tool page show both outcomes: one pair that fails on a missing package, and one pair that passes.
Quick guide
How to use this tool
- 01Copy the full contents of your project's package.json file.
- 02Copy the full contents of pnpm-lock.yaml or package-lock.json.
- 03Paste both files into the boxes and choose the lockfile type, or leave auto-detect on.
- 04Select Check for drift and read the frozen-lockfile verdict.
- 05Fix any missing or mismatched packages, then re-check before pushing.
Capabilities
Features and supported formats
- Compares every declared dependency, devDependency, peerDependency, and optionalDependency against the lockfile.
- Reads pnpm-lock.yaml (v8 and v9 layouts) and package-lock.json (lockfileVersion 1, 2, and 3).
- Names the exact missing package and shows the declared range beside the locked version.
- Flags stale lockfile entries as warnings without failing the verdict.
- Reports ranges it cannot evaluate instead of guessing a FAIL.
- Parses everything in your browser; no file is uploaded anywhere.
Supported formats
Inputs: package.json text and pnpm-lock.yaml or package-lock.json text. Output: a per-package drift table with a frozen-lockfile verdict and a copyable summary.
Answers
Frequently asked questions
What is lockfile drift?
Lockfile drift is a mismatch between package.json and the lockfile: a declared dependency with no lockfile entry, a locked version outside its declared range, or a locked package that was removed from package.json. Drift usually appears after a dependency is added, changed, or removed without regenerating and committing the lockfile.
What does ERR_PNPM_OUTDATED_LOCKFILE mean?
It means pnpm found that pnpm-lock.yaml is out of date with package.json while installing with the frozen-lockfile option, which refuses to update the lockfile. The install stops instead of guessing. Running pnpm install locally and committing the updated lockfile is the fix; this checker names the exact package that is missing or mismatched before you push.
Does the Lockfile Drift Checker upload my files?
No. Both files are parsed only in your browser tab. Nothing is sent to a server, and the contents never leave your device. Avoid pasting secrets into any online tool, including this one: lockfiles can contain private registry URLs.
Does it support npm package-lock.json as well as pnpm-lock.yaml?
Yes. Paste a package-lock.json file (lockfileVersion 1, 2, or 3) or a pnpm-lock.yaml file (v8 or v9 layouts), and the checker reads the locked versions from the packages section or the packages and snapshots sections. Auto-detect chooses the format from the content, or you can pick the type yourself.
Why does the checker say a range cannot be verified automatically?
Some ranges cannot be checked from the two files alone: workspace: and file: references, git URLs, and complex unions. The checker reports those as cannot verify automatically and leaves them out of the verdict, rather than risking a false FAIL. Every ordinary caret, tilde, exact, and comparator range is checked.
What should I do when the checker reports a FAIL?
Run pnpm install for a pnpm project or npm install for an npm project in the project folder, which regenerates the lockfile from package.json. Confirm the lockfile now lists every declared package, commit the updated lockfile together with the package.json change, and run the checker again before deploying.