How to Use Breakpoints, Conditional Breakpoints, and Logpoints in VS Code

A breakpoint tells the debugger to pause your program at a specific line. VS Code supports seven types of breakpoints. Each one solves a different debugging problem. This guide covers all of them so you can pick the right tool for the situation.

This guide assumes you already know how to start a debug session. If you have not used the Run and Debug view before, start there first.

Standard breakpoints

Click in the left margin of the editor, next to a line number. A red filled circle appears. You can also place the cursor on a line and press F9. Press F9 again or click the red circle to remove it.

When execution reaches that line, the debugger pauses. The line highlights in yellow. The VARIABLES and CALL STACK sections populate with current values.

To disable a breakpoint without removing it, right-click the red circle and select Disable Breakpoint. The circle turns gray. The breakpoint stays in your list but the debugger ignores it. Right-click again and select Enable Breakpoint to reactivate it.

All breakpoints across every file appear in the BREAKPOINTS section of the Run and Debug view. You can enable, disable, or remove them from that list without scrolling through your source files. By default, breakpoints are shown in a flat list. To group them by file, set debug.breakpointsView.presentation to tree in Settings.

Conditional breakpoints

A conditional breakpoint pauses execution only when a condition you specify is met. Instead of stopping every time, it stops only when a variable has a specific value, when an expression becomes true, or after a certain number of hits.

Right-click in the left gutter and select Add Conditional Breakpoint. VS Code asks what type of condition you want.

Expression condition

The breakpoint pauses when the expression evaluates to true. Type any valid expression in the current language.

For example, to pause only when a loop variable i exceeds 100, set the expression to i > 100. To pause only when a user object has a specific ID, use user.id === "abc123".

The expression runs in the same scope as the line where the breakpoint sits. You can access local variables, function parameters, and object properties. If the expression throws an error, the breakpoint does not pause and the error appears in the Debug Console.

Hit count condition

The breakpoint pauses only after it has been hit a certain number of times. Type a number in the hit count field. The breakpoint pauses on that Nth hit and ignores all previous hits.

This is useful for loops. If you know a bug appears on the 50th iteration, set a hit count of 50. The debugger runs through the first 49 iterations without pausing, then stops on the 50th so you can inspect the state.

Wait for breakpoint (triggered breakpoints)

This condition activates the breakpoint only after a different breakpoint has been hit. Right-click the gutter, select Add Triggered Breakpoint, and choose which other breakpoint to wait for from the list.

Triggered breakpoints help when a bug only appears after a specific code path runs. Set a normal breakpoint at the precondition, then set a triggered breakpoint at the failure point. The failure breakpoint remains dormant until the precondition fires.

Logpoints

A logpoint is a breakpoint that does not pause execution. Instead, it prints a message to the Debug Console every time that line runs.

Right-click in the left gutter and select Add Logpoint. Type the message you want to log. Include expressions in curly braces to print variable values. For example:

text

User {user.name} logged in at {new Date().toISOString()}

The logpoint appears as a diamond-shaped icon instead of a circle. When the line executes, the message appears in the Debug Console with the evaluated expressions filled in.

Logpoints replace temporary console.log or print statements. You never need to add logging code to your source and remember to remove it later. Disable or remove the logpoint when you are done.

Logpoints can also have conditions and hit counts. Right-click the diamond and select Edit Logpoint to add a condition. The message only prints when the condition is true.

Inline breakpoints

An inline breakpoint pauses execution at a specific column within a line. This matters when multiple statements sit on the same line, which is common in minified code, lambda expressions, or single-line callbacks.

Place your cursor on the exact position within the line and press Shift+F9. A small red marker appears at that column. When the debugger reaches that column, it pauses.

If a line has multiple inline breakpoints, you can edit or remove them individually by right-clicking the left gutter.

Function breakpoints

A function breakpoint pauses when a named function is called, even if you do not have the source file open. You only need the function name.

In the BREAKPOINTS section of the Run and Debug view, click the + button. Type the function name and press Enter. A red triangle appears in the breakpoint list.

Function breakpoints are useful when you know which function is misbehaving but do not know where it is defined, or when the function is in a compiled library without accessible source.

Not all debugger extensions support function breakpoints. The built-in Node.js debugger and the Python debugger both support them.

Data breakpoints

A data breakpoint pauses when the value of a specific variable changes, is read, or is accessed. This is the most targeted way to catch state corruption.

During an active debug session, right-click a variable in the VARIABLES section. Select Break on Value Change, Break on Value Read, or Break on Value Access. A red hexagon appears in the breakpoint list.

Data breakpoints are supported by a subset of debuggers, including the C++ and C# extensions. The Node.js debugger does not support them natively.

Manage breakpoints from the BREAKPOINTS section

The BREAKPOINTS section at the bottom of the Run and Debug view shows every breakpoint in your workspace. Each entry shows the file name, line number, and breakpoint type icon.

From this section you can:

• Enable or disable a breakpoint with the checkbox next to it.
• Edit the condition by clicking the pencil icon.
• Remove a breakpoint with the X icon.
• Remove all breakpoints with the trash icon in the section header.
• Activate or deactivate all breakpoints with the toggle in the section header. Deactivated breakpoints are grayed out but preserved.

Use Ctrl+Alt+F (Windows/Linux) or Cmd+Opt+F (macOS) to filter breakpoints by file name or condition text.

When to use each breakpoint type

Start with a standard breakpoint. If you find yourself pressing Continue too many times, convert it to a conditional breakpoint. If you do not want to pause at all, convert it to a logpoint.

Once you have paused at the right moment, learn how to inspect variables, watch expressions, and navigate the call stack.