How to Check Node.js Version, npm and nvm

Run node --version to check the Node.js executable selected by your current terminal. The short form, node -v, reports the same information. Check npm separately with npm --version; its version number does not tell you the Node version. If a project works in one terminal but fails in another, identify the executable before changing installations.

Check Node and npm separately

Open your terminal, Command Prompt or PowerShell and run:

node --version
npm --version

Our local Linux check on 30 September 2026 returned the following two lines, in that order. They are observations from that environment, not recommended versions to copy into every project.

v24.19.0
11.9.0

The Node CLI documentation defines the version flag. The npm version flag identifies the npm CLI. These tools have separate release numbers. Do not substitute npm version patch: that is a package-version change, not this inspection command.

Find the Node executable behind the result

Run these commands in the same context as the failing command:

node -p "process.version"
node -p "process.execPath"

The first prints the version of the newly launched Node process; our check returned v24.19.0. The second prints its absolute executable path, resolving symbolic links. That path depends on your installation. Compare it between terminals or between a terminal and an IDE task to see whether they launch the same executable. Node documents both properties in its process API.

A new shell process cannot report the runtime of an already-running web service. A container, CI job or service manager can start Node from a different installation and retain it after your terminal changes. Collect the version from that context using its normal diagnostic or startup record. Avoid printing the whole environment: the version and executable are enough for this first comparison.

Read project requirements without confusing them with installed versions

From the directory containing the intended package.json, inspect a small set of fields:

npm pkg get engines packageManager type scripts

This uses npm's package-field reader. It reads declarations; it does not install dependencies, select Node or run the listed scripts. In a workspace repository, confirm which package you are inspecting and whether workspace selection is configured.

For our check, we created an isolated fictional package with these fields and no dependencies. This is the exact returned JSON:

{
  "engines": {
    "node": ">=24 <25"
  },
  "packageManager": "[email protected]",
  "type": "module",
  "scripts": {
    "test": "node --test"
  }
}

engines.node declares a compatibility range; packageManager records a package-manager declaration. Neither proves what production runs. The test entry is only a script definition: we did not execute it. Consult npm's manifest documentation for field semantics and enforcement behavior.

All five Node/npm commands shown above completed with exit code zero and empty standard error in our local check. npm ran with isolated empty user/global configurations and offline mode. The manifest hash stayed unchanged, and no lockfile or node_modules appeared. This establishes runtime identity and field inspection, not dependency compatibility, a successful Next.js build or production behavior.

Check nvm on macOS, Linux or WSL

If you use nvm-sh, first check whether it is available in your current POSIX shell. It is a shell function, so use command -v rather than relying on which:

command -v nvm

When nvm-sh is loaded, the following commands answer different questions:

Identify the tool before interpreting its version
Command	What it identifies	What it does not establish
`nvm --version`	The nvm-sh tool version.	The selected Node release.
`nvm current`	nvm-sh's current Node selection; it can report a selection such as `system`.	The runtime of every existing application process.
`node --version`	The Node executable launched here.	Whether the project's dependencies and tests work.
`npm --version`	The npm CLI launched here.	The Node version or the application's package version.

Our availability check used Bash without startup files and did not find nvm. We did not install it or execute nvm --version or nvm current; those instructions follow the project's documentation. An unavailable command in one shell does not prove nvm is absent from the machine. Follow its documented shell setup if that is your chosen manager. A .nvmrc file also does not, by itself, prove the shell switched versions.

NVM for Windows is a separate project. Use its own documentation for native Windows management; nvm-sh guidance applies to supported POSIX shells, including WSL, rather than automatically to PowerShell.

If Node is missing or the version is unexpected

“Command not found” or “not recognized” means that command could not be resolved in this context. Check the terminal and account you are using, the existing installation method and whether its documented shell setup has loaded. If an IDE terminal differs from a fresh terminal, compare the executable paths before adding another installation.

If Node works but npm does not, investigate the npm installation separately. If local development works but CI fails, record the CI runtime and inspect its configured image or setup step. A change to your laptop cannot establish what a build runner or deployed service uses. Keep those observations together in the Node project assessment brief.

Before you update Node.js

Record the working runtime, package manager, lockfile and deployment configuration first. Check the application and framework requirements, then select a compatible release line that remains supported. Node's live release schedule identifies support status and recommends Active LTS or Maintenance LTS releases for production; a framework's minimum Node version is not the same as a suitable production target.

Make the change through the project's existing runtime-management method in a separate development environment. Run the project's documented dependency installation, tests and build, examine native dependencies where relevant, then verify the deployment context and recovery path before rollout. This guide's inspection commands do not perform or validate those update steps.

For the application decision behind those requirements, see how Node.js and Next.js fit together. If you need help assigning the work, our Node.js developer hiring guide explains what evidence to ask for, and our JavaScript development page connects these choices to implementation support.