How to Fix “Port Already in Use” for Node.js on Windows

If you run a Node.js app and see an error like `EADDRINUSE`, Windows is telling you that something is already listening on the port your app wants to use. This often happens after a crash, when an old terminal session is still alive, or when another tool quietly started a process in the background. The good news is that the fix is usually straightforward once you stop guessing and identify the exact process using the port.

This guide focuses on the practical Windows workflow: find the process using the port, stop it safely, and restart your app. The commands here are based on standard Windows networking and process tools. If you are cleaning up a local web environment more broadly, the deployment readiness audit and the rest of the tutorial hub can help keep your setup predictable.

Why this error happens

A network port can only be actively bound by one process in the same way at the same time. If your Next.js app, Express server, Vite server, or another Node.js process tries to start on port `3000` while something else already owns it, the operating system blocks the new process and Node throws a port-in-use error.

The most common causes are simple: a previous dev server is still running, a background watcher did not exit cleanly, or another app happens to use the same port. The important habit is to identify the process by PID rather than killing random Node processes blindly.

Fastest fix

If you already know the blocked port, the shortest path is to find the owning PID with `netstat` and then stop it with `taskkill`.

netstat -ano | findstr :3000

taskkill /PID 12345 /F

Replace `3000` with your actual port and replace `12345` with the PID shown in the `netstat` output. After that, restart your Node.js app normally. The rest of this article explains how to do that more carefully and how to avoid false steps.

Find the process using the port

Open Command Prompt or PowerShell and run:

netstat -ano | findstr :3000

The `-a` switch shows active connections and listening ports, `-n` prints numeric addresses and ports, and `-o` adds the owning process ID. You are looking for a line where the local address ends with the port number you care about. The final column is the PID.

For example, if the output ends with `12345`, that means process `12345` owns the port. If you want to see which app that PID belongs to, run:

tasklist | findstr 12345

This extra check is useful because sometimes the process is not Node at all. It might be another local server, Docker helper, database tool, or a lingering terminal-launched process.

Stop it safely

Once you are sure about the PID, stop the process:

taskkill /PID 12345 /F

The `/F` flag forces termination. That is practical for dev servers, but it is a blunt tool. If you recognize the process and it has its own graceful shutdown path, use that first. For example, if you still have the original terminal window open, pressing `Ctrl+C` there is cleaner than forcing the process to die.

If you only want to inspect the process before stopping it, Task Manager can help. Match the PID in Task Manager’s details view to confirm what you are about to terminate. That extra check matters when you are working on a machine with several services running.

Restart your app

After the blocking process is gone, start your Node.js app again using your normal command. Examples:

npm run dev
npm start
node server.js

If the same port error returns immediately, repeat the `netstat` step. That can happen when a process supervisor restarts the old app automatically or when your new app is actually configured to start more than one conflicting listener.

PowerShell alternative

On modern Windows, PowerShell can be clearer than parsing raw `netstat` output. You can get the owning process directly:

Get-NetTCPConnection -LocalPort 3000 | Select-Object LocalAddress, LocalPort, State, OwningProcess

Then inspect the process:

Get-Process -Id 12345

And stop it:

Stop-Process -Id 12345 -Force

This PowerShell workflow is often easier to read, especially if you are already using Windows Terminal or PowerShell for your development environment.

Common cases and fixes

A previous dev server never exited

This is the most common case. A terminal window closed unexpectedly, but the process remained alive. Use the PID workflow above and stop it.

You killed the wrong process

That is why checking the PID against `tasklist` or `Get-Process` is valuable. Do not kill every Node process on a shared machine unless you are certain they all belong to your work.

The app uses a different port than you think

Many frameworks print the chosen port at startup. Check your terminal output, `.env` file, or start script before assuming the conflict is on `3000`.

A browser tab is not the problem

A browser reading from a port does not own that port. The blocking resource is a server-side process, not the tab itself.

The process keeps coming back

Look for a watcher, task runner, auto-reload tool, Docker container, or service manager restarting it in the background.

How to avoid it next time

A few habits reduce repeated port issues:

• Shut down dev servers with `Ctrl+C` instead of closing the terminal abruptly.
• Keep a consistent default port for each project when possible.
• Check `.env` files so different apps do not all default to the same port.
• Use a short troubleshooting note in your repo so future-you remembers the fix.

If you maintain several local services, this is also a good time to document your local development conventions and release checks. The contact page is there if you want help turning small recurring issues into reusable docs.

Command cheat sheet

netstat -ano | findstr :3000
tasklist | findstr 12345
taskkill /PID 12345 /F
Get-NetTCPConnection -LocalPort 3000
Get-Process -Id 12345
Stop-Process -Id 12345 -Force