Why node_modules gets so big
node_modules holds every package a project depends on, plus everything those packages depend on. A small app can pull in hundreds of packages. Each project gets its own copy, so ten old projects with similar dependencies can mean ten copies of the same files. Tools with native binaries, browser downloads or bundled compilers add more. Nothing removes these folders when you stop working on a project.
Is it safe to delete node_modules?
Yes, for any project where you still have the source. The folder contains no code you wrote. What matters is what you need to get it back:
package.jsonlists the dependencies. Without it you can't reinstall anything.- A lockfile (
package-lock.json,yarn.lock,pnpm-lock.yamlorbun.lock) records the exact versions installed. With one, a reinstall gives you the same tree. Without one, you may get newer versions, and an old project may not build the same way.
The cost of regenerating is a download and a few minutes of install time per project. If you have edited files inside node_modules by hand, those edits are lost. Patches made with a tool such as patch-package live outside the folder and are applied again on install.
Find every node_modules folder on a Mac
Open Terminal. This lists each node_modules folder under your code folder without listing the nested ones inside it. Replace ~/code with wherever you keep projects, or use ~ for your whole home folder (slower). It only reads.
find ~/code -type d -name node_modules -pruneTo see how big each one is, with the largest at the bottom:
find ~/code -type d -name node_modules -prune -exec du -sh {} + | sort -hIf Terminal asks for access to folders such as Documents or Desktop, allow it, or the results will be incomplete.
Find every node_modules folder on Windows
Open PowerShell. This lists the top-level node_modules folders under C:\code and their sizes in gigabytes. Change the path to your own projects folder. It only reads, but it can take a while on a large folder because it counts every file.
Get-ChildItem -Path C:\code -Directory -Recurse -Filter node_modules -ErrorAction SilentlyContinue |
Where-Object { $_.FullName -notmatch 'node_modules.+node_modules' } |
ForEach-Object {
$size = (Get-ChildItem $_.FullName -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum
'{0,8:N2} GB {1}' -f ($size / 1GB), $_.FullName
}Delete them safely
Option 1: move them to the Trash or Recycle Bin
This is the safest route, because you can restore a folder if you change your mind. On a Mac, open a folder from the list in Finder (for example with open ~/code/old-project), then drag node_modules to the Trash. On Windows, select the folder in File Explorer and press Delete.
On Windows you can also send a folder to the Recycle Bin from PowerShell. Replace the path with the folder you want to remove:
Add-Type -AssemblyName Microsoft.VisualBasic
[Microsoft.VisualBasic.FileIO.FileSystem]::DeleteDirectory('C:\code\old-project\node_modules', 'OnlyErrorDialogs', 'SendToRecycleBin')Very large folders can be too big for the Recycle Bin. Windows then offers to delete them permanently instead, so read that prompt before clicking Yes. Remember that the space only comes back once you empty the Trash or Recycle Bin.
Option 2: delete permanently from the command line
These commands skip the Trash. The folders are gone right away and can't be restored. Run the listing command first and make sure you want everything it shows.
On a Mac, this removes every node_modules folder under ~/code:
find ~/code -type d -name node_modules -prune -exec rm -rf {} +On Windows, in Command Prompt, this removes one folder:
rd /s /q C:\code\old-project\node_modulesOption 3: npkill
npkill is a free, open source command line tool that lists node_modules folders with their sizes and lets you pick which to remove with the arrow keys and Space. Run it from the folder you want to scan, or pass a folder with -d:
npx npkill -d ~/codeIts README warns that some installed applications need their own node_modules to work and marks those with a warning symbol. Don't remove those. Treat npkill deletions as permanent.
Bring a project back later
When you return to a project, reinstall from its folder. With npm and a lockfile, npm ci installs exactly what the lockfile lists and fails if it doesn't match package.json, which is what you want for an old project:
npm ciUse yarn install, pnpm install or bun install for projects that use those tools. Without a lockfile, npm install picks the newest versions package.json allows.
Don't forget package manager caches
Package managers also keep a shared download cache. It speeds up installs but can grow to several gigabytes. Clearing it is safe. Packages are downloaded again when needed.
- npm keeps its cache in
~/.npmon a Mac and%LocalAppData%\npm-cacheon Windows. Clear it withnpm cache clean --force. - Yarn:
yarn cache clean. - pnpm:
pnpm store pruneremoves packages no project references.
pnpm works differently from npm. On Mac and Windows it fills each project's node_modules with clones or hard links of files in one shared store. Deleting a pnpm project's node_modules therefore frees less than its size suggests. Most of the space is in the store, and pnpm store prune is how you get it back. The same kind of shared storage explains why some duplicate files on a Mac take no extra space.
What not to delete
- node_modules inside applications. Some apps, especially ones built with Electron or installed with npm globally, ship their own
node_modules. Stick to folders inside your own projects. - Projects you are actively working on, unless you are happy to reinstall.
- Projects with no lockfile that must keep working exactly as they are. Make a copy of the folder first, or generate a lockfile before deleting.
- Global installs and version managers such as
.nvm,.fnmor.volta. They hold Node itself, not one project's packages.
If you write other kinds of code too, the same clean-up idea applies to Xcode build folders and Docker's disk image.
Seeing all of it at once
The commands above work with nothing extra installed. freedisk.space does the same search as part of a normal disk scan and shows every node_modules folder in its Developer Storage view, grouped by project, with when the project was last changed. It marks dependency folders for review, says that they are downloaded again on the next install, and warns when a project has no lockfile, so a reinstall might not match. It also lists the npm, Yarn and pnpm caches as reclaimable. Nothing is deleted from the app directly. You add folders to a Cleanup list, review it, and confirm before anything moves to the Trash on a Mac or the Recycle Bin on Windows.
Questions people ask
- Is it safe to delete node_modules?
- Yes, as long as the project still has its package.json. Running npm install, npm ci or your package manager’s install command recreates it. Keep the lockfile so you get the same versions back.
- How do I find all node_modules folders on my computer?
- On a Mac, run find ~/code -type d -name node_modules -prune in Terminal, replacing ~/code with your projects folder. On Windows, use Get-ChildItem with -Recurse and -Filter node_modules in PowerShell, or a tool such as npkill.
- How do I get node_modules back after deleting it?
- Open a terminal in the project folder and run npm ci if there is a package-lock.json, or npm install if there is not. For Yarn, pnpm or Bun projects, run that tool’s install command.
- Does npkill move folders to the Trash?
- Its README does not say it uses the Trash, so treat npkill deletions as permanent. Move folders to the Trash or Recycle Bin yourself if you want a way back.
- Why did deleting a pnpm project’s node_modules free so little space?
- pnpm fills node_modules with clones or hard links of files in one shared store, so most of the space lives in the store. Run pnpm store prune to remove packages that no project uses.
- Can I delete node_modules while the project is open in my editor?
- Stop any dev server or watcher first, because a running process can recreate files or lock them on Windows. Your editor will show import errors until you reinstall.