Fix 'npm ERR! code EINTEGRITY' When Installing npm Packages

What's Going On

You run npm install and get slapped with this:

npm ERR! code EINTEGRITY
npm ERR! Verification failed while extracting lodash@4.17.21:
npm ERR! sha512-... integrity checksum failed when using sha512: wanted sha512-ABC... but got sha512-XYZ...

npm downloads a package, then compares its checksum against the value stored in package-lock.json. They don't match. npm stops dead — it can't tell if the file was corrupted in transit, tampered with, or just a stale cache hit. So it bails.

Root Causes

• Corrupted npm cache — the culprit in most cases. A cached tarball got mangled by a disk error, an interrupted download, or antivirus software scanning mid-write.
• Stale package-lock.json — the lock file has a hash from an older package version that no longer matches what the registry serves today.
• Partial download — the network dropped mid-download. npm cached the broken file and keeps reusing it on every subsequent install.
• Registry mismatch — you switched between the public npmjs.org registry and a private Nexus or Artifactory mirror. The hashes simply don't line up across registries.
• Leftover node_modules — old install artifacts from a previous package manager run conflicting with the current resolution.

Step-by-Step Fix

Step 1 — Clear the npm cache

Start here. This resolves the error in roughly 90% of cases.

npm caches downloaded tarballs under ~/.npm on Linux/macOS, or %APPDATA%\npm-cache on Windows. One corrupted entry poisons every install until you wipe it.

npm cache clean --force

Then verify the cache is actually empty:

npm cache verify

A successful clear looks like this:

Cache verified and compressed (~/.npm/_cacache):
Content verified: 0 (0 bytes)
Index entries: 0
Finished in 0.234s

Now retry npm install. If it works, done.

Step 2 — Delete node_modules and the lock file

Cache still clean but error persists? Wipe the local install state entirely.

# Linux / macOS
rm -rf node_modules package-lock.json

# Windows (PowerShell)
Remove-Item -Recurse -Force node_modules
Remove-Item package-lock.json

Then reinstall fresh:

npm install

npm fetches everything directly from the registry and writes a brand-new package-lock.json with correct hashes. No stale data, no mismatch.

Step 3 — Install with --prefer-online

Need to preserve the lock file — say, because your team commits it? Skip the cache without deleting anything:

npm install --prefer-online

This tells npm to always pull from the registry instead of the local cache. As a fallback on older npm versions:

npm install --cache /tmp/empty-cache

Step 4 — Check your registry

Switched between a corporate registry and the public one recently? Mismatched hashes are expected — each registry signs packages differently.

npm config get registry

Pointing somewhere unexpected? Reset it:

npm config set registry https://registry.npmjs.org/

If your setup requires the corporate registry, talk to your infra team. They need to publish the correct integrity hashes on that mirror.

Step 5 — Target just the failing package

The error message names the offending package. If it's only one, don't nuke everything — just reinstall that package:

npm install lodash@4.17.21 --prefer-online

Or uninstall and re-add it cleanly:

npm uninstall lodash
npm install lodash

Step 6 — Update npm itself

npm versions below 8 had known bugs in integrity checking. Check your version first:

npm --version

Below 8? Update:

npm install -g npm@latest

Verifying the Fix

Run a clean install:

npm install

See added 847 packages (or whatever your count is) with no errors? You're good. Double-check the dependency tree is clean:

npm ls --depth=0

No warnings, no missing packages — you're done.

Manual Hash Verification (Optional)

Want to see what hash npm is actually checking? Open package-lock.json and find the package entry:

"lodash": {
  "version": "4.17.21",
  "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
  "integrity": "sha512-v2kDE..."
}

That integrity field is a base64-encoded SHA-512 hash. To verify a tarball manually, the Hash Generator on ToolCraft computes MD5, SHA-256, and SHA-512 hashes in the browser — nothing leaves your machine. Handy when you're debugging a corporate artifact mirror and need to compare hashes without spinning up a CLI tool.

Prevention

• Always commit package-lock.json — every developer and every CI run installs the exact same versions with verified hashes.
• Use npm ci in CI instead of npm install. It's stricter: errors if the lock file is missing or out of sync, and always installs from scratch. No surprises.
• Don't mix package managers — running yarn and then npm in the same project corrupts lock files fast.
• Add npm cache verify as a CI preflight — if your pipeline caches the npm cache between builds, a quick verify step catches corruption before it breaks installs.

Quick Reference

# Fix 1: Clear cache (try this first — works 90% of the time)
npm cache clean --force && npm install

# Fix 2: Full clean reinstall
rm -rf node_modules package-lock.json && npm install

# Fix 3: Skip cache, pull directly from registry
npm install --prefer-online

# Fix 4: Reset to public registry
npm config set registry https://registry.npmjs.org/ && npm install

# Fix 5: Update npm
npm install -g npm@latest