The integrity field in package-lock.json holds a Subresource Integrity hash, usually sha512, of the package archive that was unpacked at that location. When npm installs from the lockfile it can compare the downloaded tarball to that hash. A mismatch means the bytes are not what the lockfile recorded.
What the docs say
npm's lockfile documentation describes integrity as a sha512 or sha1 Standard Subresource Integrity string for the artifact that was unpacked in the location. For git dependencies it is the commit sha. A resolved field gives the tarball location, and for registry sources it is a path relative to the configured registry URL.
What integrity catches
| Situation | Caught? |
|---|---|
| A registry or proxy serves different bytes for the same version | Yes, the hash will not match |
| A tarball corrupted in transit | Yes |
| A mirror that rewrote a package | Yes |
| A maintainer publishes a new malicious version | No |
| You regenerate the lockfile and pick up that new version | No, the new hash is recorded as normal |
The hash proves sameness with what you locked, not goodness. It protects the time between locking and installing.
The real risk is the lockfile diff
Because the hash comes from whatever was resolved when the lockfile was written, a changed entry is a trust decision. Reviewers should read lockfile diffs for:
- New packages that the pull request did not mention.
- Changed resolved URLs, especially a different host.
- Integrity values that changed while the version did not. That should be rare and worth a question.
- Downgrades or jumps across many versions.
Habits that keep the control meaningful
- Commit the lockfile.
- Use the install command that respects the lockfile in CI, so it fails rather than silently updating. Compare frozen lockfile flags across tools.
- Route installs through a registry you control if you need a stable source.
- Run a dependency scan on every pull request so a new version is checked when it is introduced.
- Do not edit integrity values by hand to make an error go away. Find out why it changed.
Safeguard's SBOM and dependency scanning checks the resolved packages in a lockfile against known vulnerabilities, with reachability analysis to show which findings your code can actually hit.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the direct list with the transitive list, since lockfile entries cover both.
Quick check
Does a matching integrity hash mean the package is safe?
No. It means the bytes match what was locked. If the locked version was malicious, the hash will match that.
What does integrity hold for a git dependency?
The commit sha, according to npm's lockfile documentation.
Sources
Last reviewed: 19 October 2026.
