How to Delete All node_modules Folders on a Mac and Reclaim Gigabytes (2026)

If you have been writing JavaScript or TypeScript on your Mac for more than a year, there is a good chance that stale node_modules directories are quietly consuming tens of gigabytes across old project folders you have not touched in months. Learning how to delete all node_modules folders on a Mac is one of the fastest ways to reclaim real disk space without touching anything you actually need. This guide walks through the Terminal one-liner, a safer interactive approach, and what to watch out for before you run any deletion command.

Why node_modules Gets So Large

Every time you run npm install, yarn, or pnpm install, the package manager writes a full copy of every dependency — including deeply nested transitive dependencies — into a node_modules folder inside your project. A modest React or Next.js project can have 200–400 MB of node_modules. Multiply that across a dozen side projects and the total climbs quickly.

The key insight is that node_modules is always reproducible. As long as your package.json and lock file (package-lock.json, yarn.lock, or pnpm-lock.yaml) are intact, you can always run the install command again and get an identical directory back. That makes stale node_modules one of the safest categories of data to delete — with one important caveat covered below.

Step 1: Find All node_modules Folders

Before deleting anything, it is worth seeing what you are dealing with. Open Terminal and run:

find ~ -name "node_modules" -type d -prune 2>/dev/null

The -prune flag tells find not to descend into a matched directory, which prevents it from listing every file inside each node_modules folder and makes the output readable. The 2>/dev/null suppresses permission errors for directories you cannot read.

To see the disk usage of each hit alongside its path, pipe through du:

find ~ -name "node_modules" -type d -prune -exec du -sh {} \; 2>/dev/null

This may take a minute on a large home directory. When it finishes you will have a clear picture of which projects are the biggest offenders.

Step 2: Remove node_modules Recursively with One Command

Once you are comfortable with what will be removed, the standard one-liner to remove node_modules recursively across your entire home folder is:

find ~ -name "node_modules" -type d -prune -exec rm -rf {} \; 2>/dev/null

What this does: for every directory named node_modules found under your home folder, it runs rm -rf to delete the entire tree.

What this does not do: it does not delete your source code, your package.json, your lock files, or any other project files. Only the node_modules directory itself is removed.

Limiting the Search to a Specific Projects Folder

If all your projects live in a single directory (e.g. ~/Projects or ~/dev), you can narrow the scope and make the command faster:

find ~/Projects -name "node_modules" -type d -prune -exec rm -rf {} \; 2>/dev/null

A Safer Preview Before Deleting

If you want to review the list one final time before committing, print first, then delete:

# Preview
find ~/Projects -name "node_modules" -type d -prune 2>/dev/null

# Delete once you are satisfied
find ~/Projects -name "node_modules" -type d -prune -exec rm -rf {} \; 2>/dev/null

What Is Safe to Delete — and What Is Not

Deletion is permanent. Before running the command, confirm the following:

• Safe: any node_modules folder that sits alongside a package.json and a lock file. You can always run npm install to restore it.
• Use caution: global tool installations live in a different location (e.g. /usr/local/lib/node_modules or the path reported by npm root -g). The one-liner above targets your home directory, so global installs are typically not affected — but if you have changed your npm prefix, double-check.
• Use caution: projects with local patches applied via patch-package or manual edits inside node_modules. Those changes live only in node_modules and will be lost. Commit patches to source control before deleting.
• Not safe: actively running development servers. Stop all local servers before deleting their node_modules, otherwise the running process may behave unpredictably.

Restoring node_modules After Deletion

Restoring is straightforward. Navigate to any project whose node_modules you deleted and reinstall:

# npm
cd ~/Projects/my-app && npm install

# yarn
cd ~/Projects/my-app && yarn

# pnpm
cd ~/Projects/my-app && pnpm install

If a lock file is present, the package manager pins exact versions and the result is deterministic. If no lock file exists, the latest compatible versions are fetched — which is another reason to always commit your lock files.

Finding node_modules That Are Taking Up Space: A GUI Approach

The Terminal approach works well, but it is all-or-nothing. If you want to browse visually, see disk usage per project, and decide folder by folder which ones to remove, a disk visualization tool is more practical.

Crumb includes a whole-Mac audit that scans every folder on your drive and surfaces the largest items, including every node_modules directory it finds. You can sort by size, see which projects are genuinely stale based on last-modified dates, and delete individual folders without writing a single Terminal command. Because Crumb is a native macOS app, the scan is fast and the results appear in a browsable tree rather than a wall of Terminal output.

This is particularly useful if you are not sure which projects you still actively use and want to make selective decisions rather than wiping everything at once.

Quick Comparison: Terminal vs. GUI Approach

Other Places node_modules Hides on a Mac

Beyond your projects folder, a few other locations are worth checking if you are doing a thorough cleanup:

• Global npm packages: $(npm root -g) — usually /usr/local/lib/node_modules or inside a version manager like ~/.nvm/versions/node/<version>/lib/node_modules. Only remove packages you no longer use via npm uninstall -g <package>.
• Electron app caches: some Electron-based dev tools cache node_modules under ~/Library/Application Support/. These are managed by their respective applications and should not be deleted manually.
• CI/CD runner caches: if you run a local GitHub Actions runner, cached node_modules may appear under ~/actions-runner or a similar path. These are safe to clear if the runner is not actively using them.

Automating the Cleanup

If you accumulate project folders frequently, it is worth building a cleanup step into your workflow. A few options:

1. Add a shell alias to your ~/.zshrc: alias clean-nm='find ~/Projects -name "node_modules" -type d -prune -exec rm -rf {} \; 2>/dev/null'
2. Run the cleanup command before archiving or backing up an old project.
3. Use Crumb's whole-Mac audit periodically to catch large items — including node_modules that have grown since your last cleanup. You can download Crumb and run a scan in a few minutes.

Conclusion

Stale node_modules folders are among the most recoverable disk hogs on a developer's Mac. The Terminal one-liner is fast and effective for a bulk cleanup; a disk visualization tool is better when you want to be selective. Either way, the cleanup is safe as long as you have your lock files committed — and restoring a project is as simple as running npm install again. Clean once, and then make it part of your regular project hygiene.