Find out which installation supplies node before removing anything. Uninstalling one nvm-managed version, removing nvm itself, and removing a separate Homebrew or installer-package Node are different jobs—and one can leave the others in place.

Keep your project folders, manifests, lockfiles, and local data out of the removal plan. The official nvm documentation describes nvm as a per-user, per-shell version manager, not a manager of your project source. Its uninstall instructions concern the manager's installation directory and shell initialization, not a sweep of your development folders.

Choose one outcome, not three accidental ones

  • Remove an unused Node version: keep nvm and use its per-version uninstall command.
  • Stop nvm loading in new terminals: remove its shell initialization first. You can inspect the result before deleting any installed runtime.
  • Remove nvm and all the versions stored under its root: inventory that directory and global tools, then remove the verified manager folder.
  • Remove every Node installation: identify each owner separately. nvm uninstall does not act as an uninstaller for an independent Homebrew or vendor installation.
  • Recover disk space from old project dependencies: that is a different task. Do not confuse node_modules with the runtime itself. Preserve project-local changes, installation configuration, and access to required dependencies before treating a dependency directory as recreatable.

The installation-origin decision matters more than any universal list of files to delete.

1. Identify the Node your shell is actually using

Start in your usual terminal with these diagnostics:

command -v node
type -a node
command -v npm
command -v nvm
node --version

If a command is not found, record that rather than trying to install something to continue. type -a node can expose multiple matches on the current PATH, but cannot discover every runtime stored elsewhere.

nvm is a shell function, so nvm's verification instructions recommend command -v nvm, not treating it as an ordinary executable. When nvm is loaded, add:

nvm current
nvm ls
printf '%s\n' "$NVM_DIR"

Record the current version, installed versions, aliases, and the root directory. A path under your verified nvm root points toward the nvm branch. A Homebrew path points toward a package-managed branch, but check the package inventory rather than deciding ownership from the pathname alone.

Do not infer that a Node executable under /usr/local/bin must be a vendor .pkg installation. Other installers or links can use that location too. If ownership remains unclear, stop at diagnostics rather than guessing which files are safe to remove.

2. Save project requirements and global-tool inventories

Before switching or removing versions, back up the project directories you care about. Keep package.json, the relevant lockfile, .nvmrc where used, local configuration, uncommitted source changes, and any local databases or fixtures. Check that those folders are outside the manager root you plan to remove.

The .nvmrc section of nvm's documentation explains how projects specify a Node version. Keep that requirement even when uninstalling the runtime: it tells a future maintainer what the project expects. Removing the runtime can prevent builds from running without deleting their source.

For the current version, inspect global packages:

npm ls --global --depth=0

The npm list documentation documents global mode and depth. Save the output privately. If you use several nvm versions, select each version intentionally with nvm use and record its global list before removal. Switching versions changes the current shell environment; it is not just an inspection command.

nvm's global-package migration documentation treats packages as version-specific state worth migrating. A list is only an inventory: custom configuration, linked local packages, and package data may need separate backups. Do not assume that every missing global command can be recreated identically from a name alone.

3. Remove one nvm-managed version, if that is the whole task

Read nvm ls and choose the exact installed version to remove. Check project .nvmrc files and your recorded default alias before deciding it is unused.

If that version is currently active, first switch to a version you are keeping, or use nvm's documented nvm deactivate command to restore the shell's PATH. Do not remove a version while relying on it for an ongoing build or server.

Then use nvm uninstall VERSION, replacing VERSION with the specific installed version from your inventory. This is a removal command: it deletes that managed version and can remove the global tools stored with it. The command is documented by nvm; it does not remove the nvm manager or a separate system installation.

Run nvm ls afterward and check your aliases. If an alias points to the removed version, adjust it deliberately to a kept version rather than deleting every alias. Test a project with the intended runtime before calling the change complete.

4. Remove nvm itself with a directory-review gate

nvm's official manual uninstall consists of unloading the manager, deleting its installation directory, and removing initialization lines from shell configuration. Here, use a Finder review instead of copying a recursive-delete command.

First record the actual NVM_DIR while nvm is still loaded. The common default is $HOME/.nvm, but the installation instructions permit a different location. If the variable is unset or ambiguous, locate the directory referenced by your shell's nvm initialization before proceeding. Do not substitute your home directory or a project directory.

Back up your shell configuration files, then open the ones you actually use in a text editor—commonly .zshrc, .bashrc, or .bash_profile. Remove only the nvm initialization block: its NVM_DIR assignment, the line sourcing nvm.sh, and its bash-completion line if present. Also review any custom directory-change hook that automatically calls nvm use. nvm documents initialization and deeper shell integration in its README.

Use nvm unload in the old session as documented, then open a fresh terminal to check the result. Editing a startup file does not retroactively change every terminal or IDE process already running.

Finally, use Finder's Go > Go to Folder to open the verified nvm directory. Inspect its contents, confirm your needed inventories and backups are elsewhere, and move that exact folder to Trash. This alternative defers permanent deletion until you empty Trash; it is not a guarantee that moving it back restores every shell setting or running tool. If it contains custom files or project source, resolve those first. Removing the manager root also removes the runtimes stored inside it.

5. Handle a separate Node installation by its owner

Open a fresh terminal and repeat command -v node and type -a node. A remaining executable may belong to an independent installation; it does not necessarily mean the nvm removal failed.

For Homebrew, identify the exact brew executable and prefix, then inspect its formula list. Node may be installed under a versioned formula rather than the unversioned node name. Use the exact formula returned by your inventory.

Before removal, use that installation's brew uses --installed FORMULA to check known dependents. When removal is intended, use its documented brew uninstall --formula FORMULA. This is destructive package removal and may affect other tools; do not bypass dependency warnings. Both commands are documented in the Homebrew manpage. Keep the Homebrew manager unless you mean to remove the whole toolchain.

For a vendor .pkg or another manager, consult that installer or manager's current guidance for your actual version. This guide does not provide an unverified receipt ID or file-deletion list for Node installer packages. The general Mac uninstall guide explains why installer ownership matters, but a receipt or matching filename alone should not become an automatic deletion plan.

6. Verify the outcome you wanted

In a new terminal, check command -v nvm, command -v node, type -a node, and, if Node remains, node --version. A new terminal is a first check, not proof of a clean environment: it can inherit PATH from an already-running terminal app or IDE, or a startup hook can select the old runtime again.

If a fresh terminal still resolves the old nvm binary, inspect printf '%s\n' "$PATH" and the exact path reported by command -v node. Compare it with the recorded nvm root. In a text editor, check your shell's actual startup files for leftover nvm sourcing, hard-coded paths under that root, and custom .nvmrc/directory-change hooks. nvm's documented shell integration includes hooks that call nvm use automatically. Do not replace your whole PATH or delete an unfamiliar binary to hide the result.

Quit and relaunch the terminal application and IDE, not just a tab, then repeat the diagnostics. If the old path persists, investigate the parent application's inherited environment and shell startup chain; ask your administrator if their source is unclear. If the remaining binary is outside the verified nvm root, identify its separate installation owner before removing it.

Success is not always “command not found.” If you kept another runtime, success is that the correct installation supplies Node and your projects still have their required files. If you removed all identified runtimes, expect builds to stop until you provision a replacement. Do not delete npm caches, credentials, or project dependencies merely to make the uninstall look complete.

FAQ

Does uninstalling nvm delete my projects?

Its documented removal targets the nvm installation directory and shell initialization. Projects outside that directory are not part of the plan. Still inspect a custom root before removing it: any source or custom data placed inside it would be affected too.

Why does Node still work after I remove nvm?

Another installation may now be first on PATH, or an old terminal may retain earlier environment state. Open a fresh terminal, check all current node matches, and identify the remaining installation's owner before removing anything else.

Can I remove one Node version without removing nvm?

Yes. nvm documents nvm uninstall VERSION for a specific managed version. Inventory its global tools and project requirements first, and switch away from the version you are removing.

Will I keep my globally installed npm tools?

Not necessarily. Global packages can belong to the managed version being removed. Record npm ls --global --depth=0 for each relevant version and separately preserve configuration or data those tools need.

Should I delete node_modules to uninstall Node?

No. A project's dependency folder is a separate cleanup decision, not the runtime's installation. Keep the source, manifests, lockfiles, and local data intact, and remove only the installation you identified.

Planned Node review, not an available repair tool

SwoopByte Uninstaller is not publicly released. Planned toolchain support includes nvm and Node .pkg installations, with detection and sizes free and removal in Pro. Join the Uninstaller waitlist if that review would help. Until release, use the installation-origin workflow above; do not expect a downloadable app or a backup service.