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
- Open the Command Palette (
Ctrl+Shift+P/Cmd+Shift+P). - Run Debug: JavaScript Debug Terminal.
- In that terminal, run your app the usual way:
node app.js,npm run dev,npx tsx src/index.ts. - 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
- Start your app with
node --inspect app.js. - Open
chrome://inspectin Chrome (oredge://inspectin Edge). - Under Remote Target, click inspect next to your script. If it's missing, click Configure and make sure
localhost:9229is listed. - 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_DEBUGturns on debug output from Node's core modules:NODE_DEBUG=http,net node app.js. See the Node CLI docs.DEBUGis used by the populardebugnpm 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:
- Run TypeScript directly. Current Node versions strip types natively (
node src/index.ts), and tools liketsxwork too. Debug them in the JavaScript Debug Terminal. - Compile first. Set
"sourceMap": trueintsconfig.json, then debug the compiled output; VS Code maps back to your.tsfiles. 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.0on 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:9229inside 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.