Published Sep 16, 2025 ⦁ Updated Oct 11, 2026 ⦁ 6 min read

Node.js Debugger Guide: VS Code, Chrome and CLI (2026)

The best Node.js debugger in 2026 is the one already built into Node: start your app with node --inspect and attach VS Code, Chrome DevTools or WebStorm to it. VS Code's built-in JavaScript debugger is the easiest daily option, Chrome DevTools is great for CPU and memory profiling, and node inspect works over SSH with no GUI. Older tools you may still see recommended, such as node-inspector, ndb, Node Debug2 and IronNode, are abandoned and don't support current Node versions.

Everything below was tested against the official Node.js debugging guide and works on current releases (Node 24 LTS and Node 26, as of October 2026).

Node.js debuggers compared

Debugger Best for Status (October 2026)
VS Code JavaScript debugger Everyday breakpoints, stepping, watch expressions Built into VS Code, actively maintained
Chrome DevTools (chrome://inspect) CPU profiles, heap snapshots, memory leaks Built into Chrome and Edge
WebStorm / IntelliJ debugger Teams already on JetBrains IDEs Actively maintained; WebStorm is free for non-commercial use
node inspect (CLI) Servers, containers, SSH sessions Built into Node
node-inspector Nothing; replaced by --inspect Unmaintained since 2018
ndb (Google Chrome Labs) Nothing; use DevTools directly Repository archived, last release 2019
Node Debug / Node Debug2 (VS Code) Nothing Replaced by the built-in JavaScript debugger

How the Node inspector works

Every modern Node debugger talks to the same thing: the V8 inspector, enabled with a flag. The client (VS Code, Chrome, WebStorm) connects over a WebSocket.

Flag What it does
--inspect Starts the inspector on 127.0.0.1:9229; the app runs immediately
--inspect-brk Same, but pauses before your first line of code
--inspect-wait Same, but waits for a debugger to attach before running
--inspect=0.0.0.0:9230 Custom host and port (see the security note below)
node --inspect-brk server.js
# Debugger listening on ws://127.0.0.1:9229/0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e

Use --inspect-brk or --inspect-wait when the bug happens at startup, otherwise the code runs past your breakpoints before you attach.

Method 1: Debug Node.js in VS Code

VS Code ships its own JavaScript debugger (js-debug). No extension is needed.

Fastest: the JavaScript Debug Terminal

  1. Open the Command Palette (Ctrl+Shift+P / Cmd+Shift+P).
  2. Run Debug: JavaScript Debug Terminal.
  3. In that terminal, run your app the usual way: node app.js, npm run dev, npx tsx src/index.ts.
  4. VS Code attaches to every Node process started there, including child processes and test runners. Breakpoints you set in the editor just work.

This is also the answer to "how do I debug npm run dev in VS Code": you don't need a launch config at all.

Repeatable: a launch.json

Create .vscode/launch.json for a setup the whole team can share:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Debug server",
      "program": "${workspaceFolder}/src/server.js",
      "env": { "NODE_ENV": "development" },
      "skipFiles": ["<node_internals>/**", "**/node_modules/**"]
    },
    {
      "type": "node",
      "request": "attach",
      "name": "Attach to 9229",
      "port": 9229
    }
  ]
}

Press F5 to start. skipFiles keeps "step into" from wandering into Node internals and dependencies.

Auto Attach

With Auto Attach (Command Palette: Debug: Toggle Auto Attach), VS Code attaches to Node processes started in its integrated terminal. The default Smart mode skips tools like npm itself and attaches to your scripts.

Method 2: Debug Node.js in Chrome DevTools

  1. Start your app with node --inspect app.js.
  2. Open chrome://inspect in Chrome (or edge://inspect in Edge).
  3. Under Remote Target, click inspect next to your script. If it's missing, click Configure and make sure localhost:9229 is listed.
  4. Alternatively, click Open dedicated DevTools for Node, which reconnects automatically when the process restarts.

Chrome DevTools is the strongest option for performance work:

  • Performance tab: record a CPU profile while you hit a slow endpoint.
  • Memory tab: take two heap snapshots and compare them to find a leak.
  • Sources tab: breakpoints, conditional breakpoints and logpoints, the same as in the browser.

Method 3: The command-line debugger

When you're on a server or inside a container without a GUI, use the built-in CLI:

node inspect app.js

Useful commands at the debug> prompt:

Command Action
c Continue
n Step to next line
s / o Step in / step out
sb(10) Set breakpoint on line 10
repl Evaluate expressions in the current scope (Ctrl+C to leave)
watch('user.id') Watch an expression

Breakpoints in code: the debugger statement

Put debugger; anywhere in your code. When a debugger is attached, execution stops there; without one, it's ignored.

app.post('/orders', async (req, res) => {
  const order = await createOrder(req.body);
  debugger; // pauses here when a debugger is attached
  res.json(order);
});

Remove it before committing; many ESLint configs flag it with the no-debugger rule.

Debugging without a debugger: logs and environment variables

Two environment variables often get confused:

  • NODE_DEBUG turns on debug output from Node's core modules: NODE_DEBUG=http,net node app.js. See the Node CLI docs.
  • DEBUG is used by the popular debug npm package, which Express and many libraries use: DEBUG=express:* node app.js.
// npm install debug
const log = require('debug')('app:orders');
log('creating order %o', { id: 42 }); // prints only when DEBUG=app:* is set

For npm itself, npm install --loglevel verbose shows what npm is doing during install.

Debugging TypeScript and source maps

Breakpoints in .ts files need source maps. Two ways to get them:

  1. Run TypeScript directly. Current Node versions strip types natively (node src/index.ts), and tools like tsx work too. Debug them in the JavaScript Debug Terminal.
  2. Compile first. Set "sourceMap": true in tsconfig.json, then debug the compiled output; VS Code maps back to your .ts files. If breakpoints show as unbound (grey), add "outFiles": ["${workspaceFolder}/dist/**/*.js"] to your launch config.

Remote and container debugging, safely

The Node docs are blunt about this: anyone who can reach the inspector port can run arbitrary code in your process. So:

  • Never bind to 0.0.0.0 on a public machine or production server.
  • Use an SSH tunnel instead:
# on the server
node --inspect app.js
# on your machine
ssh -L 9221:localhost:9229 user@remote.example.com
# then attach your debugger to localhost:9221
  • In Docker, bind to 0.0.0.0:9229 inside the container but publish only to localhost: docker run -p 127.0.0.1:9229:9229 ....

Choosing your setup

  • Daily work: VS Code JavaScript Debug Terminal.
  • Slow endpoints or memory leaks: Chrome DevTools via chrome://inspect.
  • Already on JetBrains: WebStorm's Node.js run configurations.
  • Servers and containers: node inspect, or an SSH tunnel to your local debugger.

If you also debug C or C++ code, see our guide to online GDB debuggers. For new editors and IDEs, browse IDE tools on DevHunt, and if you're new to Node's file APIs, Node.js readFile for beginners is a good next step.

FAQ

Does Node.js have a built-in debugger?

Yes. node --inspect exposes the V8 inspector for GUI tools such as VS Code and Chrome, and node inspect app.js starts a command-line debugger. Nothing needs to be installed.

How do I debug Node.js in VS Code?

Open the Command Palette, run Debug: JavaScript Debug Terminal and start your app in that terminal. Breakpoints set in the editor will hit. For a reusable setup, add a launch.json with a "type": "node" configuration.

How do I debug Node.js in Chrome?

Run node --inspect app.js, open chrome://inspect, and click inspect under Remote Target. You get the full DevTools Sources, Performance and Memory panels for your Node process.

What is the difference between --inspect and --inspect-brk?

--inspect starts your code right away and lets a debugger attach at any time. --inspect-brk pauses before the first line, so you can set breakpoints before any startup code runs.

Is ndb or node-inspector still worth using?

No. node-inspector hasn't been updated since 2018 and ndb's repository is archived. Both were replaced by the built-in inspector, which VS Code and Chrome DevTools connect to directly.