VS Code Debugging Shortcuts
VS Code's built-in debugger turns the editor into a genuine debugging environment rather than just a text editor with a terminal attached, and these shortcuts are the core vocabulary for stepping through running code once you've moved past writing it and into figuring out why it isn't behaving as expected. Rounding out the debugging toolkit, Step Out lets you return from inside a function you've stepped into, and stopping a session entirely ends the debug run rather than just pausing it.
| Action | Windows | Mac | Description |
|---|---|---|---|
| Toggle breakpoint | F9 | F9 | Toggles a red-dot breakpoint marker in the gutter next to the current line; because VS Code's debugging runs through the Debug Adapter Protocol, the exact pause behavior depends on which debug adapter extension is active for the language, though the gutter marker and toggle key stay consistent across all of them. |
| Start debugging / continue | F5 | F5 | Starts a new debug session if none is running, or resumes execution from a paused breakpoint if a session is already active — the same key serves both purposes depending on current state. |
| Step over | F10 | F10 | Executes the current line and moves to the next one without diving into any function calls on that line, the default move when you trust the function being called and just want to keep moving through your own code. |
| Step into | F11 | F11 | Follows execution down into whatever function the current line calls, rather than skipping past it, so you can trace its internal behavior one line at a time. |
| Step out | Shift+F11 | Shift+F11 | Resumes execution until the current function returns, popping back up to whatever called it, the natural next step after using Step Into to confirm a function works correctly and wanting to return to the calling context without stepping through every remaining line individually. |
| Stop debugging session | Shift+F5 | Shift+F5 | Kills the active debug session outright rather than just pausing it, terminating the debugged process and dropping the editor back to its ordinary undebugged state. |
F9 marks or unmarks the current line with a breakpoint, visible as a small red dot sitting in the gutter next to the line numbers; once a running debug session hits that line, execution halts right there so you can look through variable values and figure out your next move. A breakpoint set once tends to stick around across debugging sessions and even a full editor restart in most workspace setups, sparing you from having to click it back into place before every fresh debug run.
F5 serves a dual purpose depending on the debugger's current state: with no active session, it starts a new debug run using whatever launch configuration is selected (defined in .vscode/launch.json); with a session already paused at a breakpoint, the same key instead resumes execution, running until the next breakpoint or the program's natural end. This dual meaning is intentional and mirrors how most other IDEs handle the same key, but it does mean F5's effect genuinely depends on context rather than always doing one fixed thing.
Once paused at a breakpoint, F10 (Step Over) and F11 (Step Into) are the two primary ways to advance execution one step at a time. Step Over executes the current line completely — including any function calls it makes — and stops at the next line in the current scope, treating called functions as a black box you trust and don't need to trace through. Step Into instead descends into a function call on the current line, letting you follow execution inside that function line by line, which is what you want when the function itself is suspect rather than just a step on the way to somewhere else.
A companion shortcut not detailed above, Shift+F11 (Step Out), resumes execution until the current function returns and control goes back to whatever called it — useful once you've stepped into a function with Step Into, confirmed it's working correctly, and want to get back out to the calling context without manually stepping through every remaining line of that function one at a time.
Step Out (Shift+F11) is the natural companion to Step Into — once you've descended into a function to trace its internals and confirmed it's behaving correctly, Step Out resumes execution until that function actually returns, popping control back up to whatever called it, without requiring you to manually step through every remaining line of that function's body one at a time to get back out.
Stopping a debug session (Shift+F5) is a distinct action from pausing — pausing (which happens automatically at a breakpoint, or manually via the debug toolbar's pause button) keeps the process alive and inspectable, ready to resume, while stopping terminates the debugged process entirely, ending the session and returning the editor to its normal non-debugging state. This matters when you've finished investigating an issue and want to genuinely end the run rather than leaving a paused process consuming resources in the background.
Conditional breakpoints, set by right-clicking an existing breakpoint's red dot and choosing to edit its condition, only pause execution when a typed expression evaluates true, which is considerably more useful than a plain breakpoint inside a loop that would otherwise interrupt execution on every single iteration rather than just the one iteration where a specific value or state is actually of interest.