Fix: Yarn error Integrity check failed / EINTEGRITY sha512

The Error

You run yarn install and get:

error Integrity check failed for "lodash" (computed integrity doesn't match our records)

Or variations:

error https://registry.yarnpkg.com/react/-/react-18.2.0.tgz:
Integrity check failed for "react" (computed integrity doesn't match our records, got "sha512-abc123...")

EINTEGRITY sha512-xyz... integrity checksum failed when using sha512

error An unexpected error occurred: "Integrity check failed for \"express\""

The downloaded package’s checksum does not match the checksum recorded in yarn.lock. Yarn refuses to install because the package might be corrupted or tampered with.

Why This Happens

Yarn stores integrity hashes (SHA-512 checksums) in yarn.lock to verify that packages have not changed since they were first resolved. When you run yarn install, Yarn downloads the tarball, computes its SHA-512, and compares it to the recorded hash. A mismatch triggers the integrity check failure and the install aborts before any code is unpacked.

The check exists for a reason: it is the only line of defense against silent supply-chain tampering. Without it, a compromised mirror, a man-in-the-middle proxy, or a malformed CDN response could swap one tarball for another and you would never know. So while the error is annoying, it is doing its job — your task is to figure out which legitimate cause is triggering it.

If they do not match, Yarn aborts to protect against:

• Corrupted downloads. Network issues caused partial or corrupted package downloads.
• Corrupted cache. The local cache contains a damaged copy of the package.
• Registry-side changes. The package was republished with different content (rare but possible).
• Lock file conflicts. The yarn.lock file has incorrect entries from merge conflicts.
• Proxy/CDN issues. A corporate proxy or CDN served a cached, outdated, or corrupted response.
• Cross-machine yarn.lock. The lock file was generated against one registry mirror, but the current machine resolves to a different mirror that serves a tarball with a different integrity field (this happens with private registries that re-pack tarballs).
• Yarn version drift. A yarn.lock written by Yarn Berry has a different integrity format than one written by Yarn Classic. Mixing tooling between developers triggers the error on the second machine that touches the file.

Platform and Environment Differences

The same EINTEGRITY error has slightly different causes depending on where you hit it.

Linux developer machine (Ubuntu, Fedora, Arch). Usually a straightforward cache corruption or an interrupted download. ~/.cache/yarn/ is on a normal ext4/btrfs filesystem with no file-locking quirks, so a single yarn cache clean plus rm -rf node_modules resolves it. If you use a system package manager Yarn install (apt install yarnpkg), be aware that the version often lags upstream by months and may write a slightly older integrity format. Prefer Corepack or the official installer for parity with CI.

macOS (Intel and Apple Silicon). Behaves like Linux for the cache layer. The notable wrinkle is the App Translocation / Gatekeeper layer on Apple Silicon — if Yarn was installed via a .pkg that runs under Rosetta on an M1/M2/M3 Mac, sha512 computation is fine but a few native dependencies that get re-resolved during install (fsevents, node-sass, sharp) can pull arch-specific tarballs whose integrity differs from what the lock file recorded on a teammate’s Intel Mac. The fix is to standardize on arch -arm64 yarn install (or the opposite) across the team and regenerate the lock file once.

Windows native (PowerShell / cmd). Windows adds two failure modes that other platforms do not have. First, file-locking: if any editor, antivirus, or another yarn install is holding a handle on a file inside node_modules\, the install can truncate a tarball mid-write and the next read computes the wrong hash. Close VS Code, stop dev servers, and disable real-time antivirus scanning of the project folder, then retry. Second, path length: Windows still has the legacy 260-character MAX_PATH limit unless long paths are enabled via group policy. Deeply nested packages can fail to extract cleanly and produce a corrupted cache entry.

WSL2. If you yarn install from inside WSL2 but the project lives on the Windows filesystem (/mnt/c/...), every file read crosses the 9P protocol bridge. This is slow and occasionally drops bytes under load, producing the integrity error intermittently. Move the project into the WSL2 filesystem (~/projects/...) and the error usually disappears. If you must keep the project on the Windows side, at least keep the Yarn cache inside WSL2 via yarn config set cacheFolder ~/.yarn/cache.

Docker. Cache mounts (RUN --mount=type=cache,target=/root/.yarn/cache) survive across builds. If the cache is shared between two images that use different Yarn versions or different registries, the integrity entries collide. Either give each image its own cache id (--mount=type=cache,id=my-app-yarn,...) or drop the cache mount for that one build to force a clean resolution.

CI runners (GitHub Actions, GitLab, CircleCI). Cache key invalidation is the usual culprit. Hosted runners migrate between physical machines, and a cache restored from a slightly different OS image can contain partial tarballs from an interrupted previous run. Always include the runner OS and Node version in the cache key (${{ runner.os }}-node${{ matrix.node }}-yarn-${{ hashFiles('**/yarn.lock') }}), and use yarn install --immutable so CI fails loud rather than silently rewriting the lock file.

Fix 1: Clear the Yarn Cache

The most common fix. The cached package is corrupted:

Yarn Classic (v1):

yarn cache clean
yarn install

Yarn Berry (v2+):

yarn cache clean --all
yarn install

Clear cache for a specific package:

yarn cache clean lodash
yarn install

Find the cache directory:

yarn cache dir
# Usually ~/.cache/yarn/v6

Pro Tip: If clearing the cache does not work, also delete node_modules before reinstalling. Corrupted files in node_modules can cause the same error even with a clean cache.

Fix 2: Delete node_modules and Reinstall

A full clean reinstall:

rm -rf node_modules
rm -rf .yarn/cache   # Yarn Berry
yarn cache clean
yarn install

Nuclear option — regenerate the lock file too:

rm -rf node_modules
rm yarn.lock
yarn install

Warning: Deleting yarn.lock regenerates it from scratch, which may update package versions. Only do this if other fixes fail and you can verify the updated versions work.

Fix 3: Fix yarn.lock Merge Conflicts

Merge conflicts in yarn.lock produce invalid entries:

<<<<<<< HEAD
lodash@^4.17.21:
  version "4.17.21"
  resolved "https://registry.yarnpkg.com/lodash/-/lodash-4.17.21.tgz"
  integrity sha512-abc...
=======
lodash@^4.17.21:
  version "4.17.21"
  resolved "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz"
  integrity sha512-xyz...
>>>>>>> feature-branch

Fixed — regenerate the lock file entry:

# Accept one side of the conflict (doesn't matter which)
git checkout --theirs yarn.lock
# or
git checkout --ours yarn.lock

# Then regenerate
yarn install

This resolves the conflict markers and regenerates the correct integrity hashes.

Common Mistake: Manually editing yarn.lock to resolve conflicts. The lock file is auto-generated — never edit it by hand. Resolve the conflict by accepting one version, then run yarn install to regenerate the correct entries.

Fix 4: Fix Registry and Network Issues

Corporate proxies or alternative registries can cause integrity failures:

Check your registry configuration:

yarn config get registry
# or for Yarn Berry:
yarn config get npmRegistryServer

Reset to the default registry:

# Yarn Classic
yarn config set registry https://registry.yarnpkg.com

# Yarn Berry
yarn config set npmRegistryServer https://registry.yarnpkg.com

If behind a corporate proxy:

yarn config set proxy http://proxy.company.com:8080
yarn config set https-proxy http://proxy.company.com:8080

Disable strict SSL (development only):

yarn config set strict-ssl false

Try using the npm registry instead:

yarn config set registry https://registry.npmjs.org
yarn cache clean
yarn install

Registry mirrors are a frequent and underestimated source of EINTEGRITY. The official npm registry, registry.yarnpkg.com (a Cloudflare proxy in front of npm), registry.npm.taobao.org / registry.npmmirror.com (Chinese mirrors used by cnpm), and self-hosted Verdaccio or Nexus instances all serve the same package versions — but the tarballs they ship can have slightly different metadata or compression, which changes the SHA-512. A lock file generated against one mirror is not portable to another. If your team mixes mirrors (one developer in China on cnpm, the rest on the default registry), every yarn install on a different machine fights the integrity check. Standardize on one registry in .yarnrc or .yarnrc.yml and commit that file so everyone resolves to the same source.

Fix 5: Update the Integrity Hash

If a package was legitimately republished, update the hash:

# Remove the specific package from the lock file and re-resolve
yarn upgrade lodash

Or for all packages:

yarn upgrade

For a specific package version:

yarn add [email protected]

This re-downloads the package and records the new integrity hash.

Fix 6: Fix Yarn Berry (.yarnrc.yml) Issues

Yarn Berry (v2/v3/v4) uses .yarnrc.yml for configuration:

Check for enableImmutableInstalls:

# .yarnrc.yml
enableImmutableInstalls: false  # Allow modifications during install

Check for checksumBehavior:

# .yarnrc.yml
checksumBehavior: update  # Update checksums instead of failing

Other options:

checksumBehavior: ignore   # Skip integrity checks (NOT recommended)
checksumBehavior: throw    # Fail on mismatch (default)
checksumBehavior: update   # Update the lock file with new checksums

Berry resolves dependencies differently from Classic. Berry uses Plug’n’Play by default (no node_modules), and the integrity field in a Berry yarn.lock is computed on the unpacked content rather than just the tarball. If you switch a project from Classic to Berry without running yarn install once to migrate the lock file, every package fails the integrity check. Run yarn set version berry followed by yarn install to migrate cleanly, and never check in a half-migrated lock file.

Fix 7: Fix CI/CD Integrity Failures

Integrity errors in CI often come from cache inconsistencies:

GitHub Actions — clear cache:

- name: Get yarn cache directory path
  id: yarn-cache-dir-path
  run: echo "dir=$(yarn cache dir)" >> $GITHUB_OUTPUT

- uses: actions/cache@v4
  id: yarn-cache
  with:
    path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
    key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
    restore-keys: |
      ${{ runner.os }}-yarn-

If cache causes issues, bust the cache:

Change the cache key to force a fresh install:

key: ${{ runner.os }}-yarn-v2-${{ hashFiles('**/yarn.lock') }}
# Change v2 to v3, v4, etc. to bust the cache

Use --frozen-lockfile in CI:

yarn install --frozen-lockfile   # Yarn Classic
yarn install --immutable          # Yarn Berry

This ensures the lock file is not modified during CI builds.

Fix 8: Downgrade or Switch Package Managers

If Yarn integrity issues persist:

Try npm instead:

rm -rf node_modules
rm yarn.lock
npm install

Use a specific Yarn version:

# Check current version
yarn --version

# Set a specific version (Yarn Berry)
yarn set version 4.0.0
yarn install

Use corepack (Node.js 16+):

corepack enable
corepack prepare [email protected] --activate
yarn install

Corepack is the most reliable way to pin Yarn across machines. It reads the packageManager field in package.json and installs that exact version on demand, so a developer on macOS, a teammate on WSL2, and a CI runner on Ubuntu all run the same Yarn binary. Without Corepack, the locally installed Yarn version drifts and quietly produces different integrity fields.

Still Not Working?

Check disk space. Corrupted downloads can happen when disk space runs out mid-download:

df -h

Check for antivirus interference. Some antivirus software modifies downloaded files, breaking integrity checks. Add the Yarn cache directory to the exclusion list. On Windows, Defender’s real-time scan is the usual culprit; on macOS, third-party tools like CrowdStrike or SentinelOne behave the same way.

Check for filesystem issues. Corrupted filesystems can cause integrity mismatches. Run a filesystem check if you suspect hardware issues. On NTFS, chkdsk C: /f; on ext4, fsck on the unmounted partition; on APFS, diskutil verifyVolume /.

Try a different network. If the issue only happens on one network, a proxy, firewall, or ISP might be interfering with the downloads.

Compare the failing tarball byte-for-byte. When you suspect a mirror is shipping a different file, download the same package version directly with curl -L -o pkg.tgz <tarball-url> from two different networks (home Wi-Fi vs. office VPN, for example) and run shasum -a 512 pkg.tgz on each. If the hashes differ, you have proof that something on the path is rewriting the response and you can escalate to your network team or registry provider.

Disable Yarn’s HTTP/2 transport. A few corporate proxies advertise HTTP/2 support but mishandle the response framing, truncating tarballs by a handful of bytes. Set httpProxy / httpsProxy to force HTTP/1.1 through a known-good proxy, or temporarily use a different network to confirm.

Reinstall Node.js itself. A broken Node binary occasionally miscomputes SHA-512 on certain CPUs (rare, but reported for older Node 14 builds on Apple Silicon). Update to the current LTS via nvm install --lts or Corepack-supported Node and retry.

For Yarn general integrity check issues, see Fix: Yarn integrity check failed. For npm dependency resolution errors, see Fix: npm ERR! ERESOLVE unable to resolve dependency tree. For npm 404 errors, see Fix: npm ERR! code E404. For Node.js module resolution problems that show up right after a successful install, see Fix: Node.js ERR_MODULE_NOT_FOUND.