npm Cache on Mac: Is It Safe to Delete?
Medium riskPackage managers & build toolsUpdated
- Location
~/.npm/_cacache
- Risk level
- Medium riskSafe to remove, but the tool that owns it re-downloads or rebuilds it on next use, which costs time and bandwidth. Listed, never pre-selected.
- Selected by default
- No — you choose whether to include it
- What Freshist does
- Moves the selected items to the Trash, so you can undo. Nothing is deleted outright.
- In the app
- Clean → npm Cache — “Package cache — future npm installs re-download packages.”
From Freshist's own cleaning rules — the same catalog the app uses.
What's inside _cacache
npm keeps a content-addressable cache under its cache directory. On a Mac the cache directory is ~/.npm and the actual store is the _cacache folder inside it. It holds three kinds of data:
- Package tarballs, stored by content hash, so the same version is saved once no matter how many projects use it.
- Registry metadata (packuments) that npm uses to resolve versions.
- An index that maps request keys to those content files.
Your code, package.json, lockfiles and node_modules folders live in your projects, not here. Next to _cacache you will usually see _logs (debug logs from failed commands) and _npx (packages fetched by npx). Those are separate folders.
Why it keeps growing
npm adds to the cache on every install and never evicts old versions on its own. Every upgrade of a dependency, every branch with a different lockfile and every CI-style clean install adds tarballs. After a year of Node work, several gigabytes is normal. On the Mac used to check this guide, du reported 2.8 GB.
What deleting it costs
| Removed | What happens next |
|---|---|
| Cached tarballs | Re-downloaded from the registry on the next npm install or npm ci |
| Cached metadata | Refetched; the first resolve after clearing is slower |
| Offline installs | npm install --offline and --prefer-offline stop working until the cache is warm again |
Projects and node_modules | Not affected |
Nothing about your login or registry configuration lives in _cacache. Auth tokens and settings sit in ~/.npmrc, which you should leave alone.
Inspect it first (read-only)
npm config get cache # prints the cache root, normally ~/.npm
du -sh ~/.npm/_cacache # size on disk
npm cache ls # list cached package specs
If a custom cache setting appears in ~/.npmrc or in the npm_config_cache environment variable, the cache lives wherever that points.
Clear it the npm way
The npm documentation describes the cache as self-healing and says clearing it is only needed to reclaim disk space. There are two official commands:
npm cache verifychecks the index and contents, garbage-collects data that is no longer needed and reports how much space it freed. It keeps valid entries, so later installs stay fast.npm cache clean --forceremoves the whole cache. The--forceflag is mandatory.
Run either from Terminal with no Node process using npm at the same time. Deleting ~/.npm/_cacache in Finder has the same effect as the clean command.
Reasons to leave it alone
A warm cache earns its space if you often work offline, pay for data, or reinstall large dependency trees across many projects. There, npm cache verify is the better tool: it clears out data npm no longer needs and keeps the packages you still use. Other package managers keep their own stores, covered in the pnpm store guide and the broader developer caches overview.
Sources
Frequently asked questions
Does clearing the npm cache fix install errors?
Rarely. npm checks the integrity of everything it reads from the cache and refetches anything corrupted, so most install errors come from the lockfile, the registry or network settings. Try npm cache verify before wiping it.
Why does npm cache clean refuse to run?
Since npm 5, npm cache clean requires --force. The npm team made it opt-in because the cache is self-healing and clearing it only makes sense when you want the disk space back.
Will deleting the cache break npx?
No. npx keeps the packages it runs in a separate ~/.npm/_npx folder, which sits next to _cacache rather than inside it. npx may be slower the first time it needs a package it hasn't fetched, but it keeps working.