What Is node_modules and Is It Safe to Delete?

If you’ve ever run a disk analyzer on a developer’s machine, one folder name shows up again and again, devouring gigabytes: node_modules. So the natural question is: is it safe to delete node_modules?

Short answer: yes. In almost every case node_modules is fully disposable, and deleting it is one of the fastest ways to reclaim disk space on a dev machine. But it’s worth understanding why it’s safe — and the couple of situations where you should pause first.

What is node_modules, exactly?

When you run npm install (or yarn, pnpm, or bun install), your package manager reads two files:

• package.json — the list of dependencies your project declares.
• package-lock.json (or yarn.lock, pnpm-lock.yaml) — the exact resolved versions.

It then downloads every dependency — and every dependency’s dependencies, recursively — into a local node_modules folder. This is why a project that declares five packages can end up with hundreds of nested folders and tens of thousands of files.

The key insight: node_modules is generated, not authored. Nothing in it is your work. It’s a local, rebuildable cache derived entirely from package.json and your lockfile.

Why it’s safe to delete

Because node_modules is reproducible, deleting it loses nothing permanent — as long as you still have your package.json and lockfile (which live in your repo and should be committed to git). To restore it, you run one command:

npm install     # or: yarn / pnpm install / bun install

Your package manager rebuilds node_modules from the lockfile, giving you the exact same versions back. In fact, deleting node_modules and reinstalling is a standard troubleshooting step for corrupted dependencies:

rm -rf node_modules
npm install

So not only is it safe — it’s a routine, recommended operation.

How much space can you reclaim?

The numbers surprise people. A single modern web project’s node_modules is often 200 MB to 1 GB+. Multiply that by every side project, tutorial, and abandoned experiment on your disk:

Scenario	Typical node_modules footprint
One small CLI tool	50–150 MB
One React/Next.js app	300 MB – 1 GB
A monorepo	1–5 GB
15 old side projects	5–20 GB

The biggest wins come from stale projects — repos you haven’t touched in months. They still carry a full node_modules, doing nothing but occupying space.

Find every node_modules folder

On macOS or Linux, you can list them by size:

find . -name 'node_modules' -type d -prune -print | xargs du -sh 2>/dev/null | sort -rh

To delete them across many projects (careful — read the next section first):

find . -name 'node_modules' -type d -prune -exec rm -rf '{}' +

That find … -exec rm -rf line is powerful and unforgiving: a typo in the path, or running it from the wrong directory, deletes far more than you intended. There’s no Trash, no undo. This is exactly the scenario where a safer workflow matters — more on that below.

When to pause before deleting

node_modules is safe to delete almost always. The exceptions:

• No lockfile committed. If a project has no package-lock.json/yarn.lock and you’re offline, reinstalling could resolve to different versions. Commit your lockfile and this risk disappears.
• Patched packages. If you use patch-package or manually edited a file inside node_modules, those edits live only there. Patches are normally re-applied on install via a postinstall script — verify that’s set up.
• A dependency was pulled from the registry. Rare, but a deleted/unpublished package could fail to reinstall. A committed lockfile plus an npm cache usually saves you.
• You’re on a plane. Only relevant if you need the project working right now with no internet. Otherwise, delete away.

None of these make deletion dangerous — they’re just reasons to confirm your lockfile is in git first.

Does pnpm or Yarn change the answer?

Modern package managers try to shrink the node_modules problem, and it’s worth knowing how that affects deletion:

• pnpm uses a single global content-addressable store (usually ~/.pnpm-store) and hard-links packages into each project’s node_modules. Deleting a project’s node_modules is still completely safe — the store stays intact, so reinstalls are fast. If you want to reclaim the shared store itself, pnpm store prune removes unreferenced packages safely.
• Yarn Plug’n’Play (PnP) can skip node_modules entirely, storing dependencies as zipped archives in .yarn/cache. There’s often no node_modules folder to delete at all — but the .yarn/cache is likewise regenerable from the lockfile.
• npm keeps its own download cache in ~/.npm. It’s safe to clear with npm cache clean --force, though npm manages its size automatically, so this is rarely worth it.

The takeaway is unchanged: whatever manager you use, per-project dependency folders are rebuildable caches. Reclaim them freely.

node_modules is just the start

If you’re reclaiming space as a developer, node_modules is the headliner, but the same “generated, safe to delete” logic applies to a lot of build clutter:

Folder / artifact	Ecosystem	Safe to delete?
node_modules	Node.js	✅ Rebuild with install
.next, dist, build	JS bundlers	✅ Rebuild with build
target/	Rust / Java (Maven/Gradle)	✅ Rebuilds on next build
__pycache__, .venv	Python	✅ Regenerated / reinstallable
DerivedData	Xcode	✅ Xcode regenerates it
~/.gradle/caches	Gradle	✅ Re-downloaded as needed
vendor/	PHP/Go (some setups)	⚠️ Usually, if managed by a lockfile

For a fuller tour of these, see our Mac disk-space guide, which covers Xcode and simulator bloat in detail.

Delete it — but keep a safety net

Here’s the tension: deleting node_modules is safe in principle, but the tools people use to do it in bulk (rm -rf, sweeping find commands) are the opposite of safe. One wrong path and you’ve deleted src/, not node_modules.

A better approach treats even “obviously safe” deletions with a recovery window:

1. Scan your disk and let the tool identify every node_modules (and target/, DerivedData, etc.) by pattern.
2. Preview the exact list and total size before anything happens.
3. Approve the batch deliberately.
4. Quarantine first, so a mistaken delete is one click to restore.

This is the model behind Declutter. It recognizes developer build artifacts, explains why each is safe to reclaim, and moves approved items to a recoverable quarantine instead of running an irreversible rm. You get the multi-gigabyte reclaim without the 1 a.m. “wait, which folder did I just delete?” moment.

The bottom line

Is it safe to delete node_modules? Yes — it’s generated from your package.json and lockfile, and npm install brings it right back. Reclaim the space freely across your old projects. Just keep your lockfiles in git, watch for the rare patched-package case, and use a workflow that quarantines before it deletes so a bulk cleanup can never turn into a bulk mistake.

---

Reclaim gigabytes of dev clutter, safely. Download Declutter to find every node_modules, target/, and cache on your disk and clear them with full undo. Ship less clutter — subscribe to our newsletter for practical, no-spam developer disk tips.