Kayce Basques

Sofia Emelianova

Use breakpoints to pause your JavaScript code. This guide explains each type of breakpoint that'savailable in DevTools, as well as when to use and how to set each type. For an interactive tutorial of the debugging process, seeGet Started with Debugging JavaScript in Chrome DevTools.

Overview of when to use each breakpoint type

The most well-known type of breakpoint is line-of-code. But line-of-code breakpoints can beinefficient to set, especially if you don't know exactly where to look, or if you are working with alarge codebase. You can save yourself time when debugging by knowing how and when to use the othertypes of breakpoints.

Line-of-code breakpoints

Use a line-of-code breakpoint when you know the exact region of code that you need to investigate.DevToolsalways pauses before this line of code is executed.

To set a line-of-code breakpoint in DevTools:

1. Click theSources panel.
2. Open the file containing the line of code you want to break on.
3. Go to the line of code.
4. To the left of the line of code is the line number column. Click it. A blue icon appears ontop of the line number column.

This example shows a line-of-code breakpoint set on line29.

Line-of-code breakpoints in your code

Calldebugger from your code to pause on that line. This is equivalent to aline-of-codebreakpoint, except that the breakpoint is set in your code, not in the DevTools UI.

console.log('a');console.log('b');debugger;console.log('c');

Conditional line-of-code breakpoints

Use a conditional line-of-code breakpoint when you want to stop the execution but only when some condition is true.

Such breakpoints are useful when you want to skip breaks that are irrelevant to your case, especially in a loop.

To set a conditional line-of-code breakpoint:

1. Open theSources panel.
2. Open the file containing the line of code you want to break on.
3. Go to the line of code.
4. To the left of the line of code is the line number column. Right-click it.
5. SelectAdd conditional breakpoint. A dialog displays underneath the line of code.
6. Enter your condition in the dialog.
7. PressEnter to activate the breakpoint. An orange icon with a question mark appears on top of the line number column.

This example shows a conditional line-of-code breakpoint that fired only when thex exceeded10 in a loop at iterationi=6.

Log line-of-code breakpoints

Use log line-of-code breakpoints (logpoints) to log messages to theConsole without pausing the execution and without cluttering up your code withconsole.log() calls.

To set a logpoint:

1. Open theSources panel.
2. Open the file containing the line of code you want to break on.
3. Go to the line of code.
4. To the left of the line of code is the line number column. Right-click it.
5. SelectAdd logpoint. A dialog displays underneath the line of code.

6. Enter your log message in the dialog. You can use the same syntax as you would with aconsole.log(message) call.

   For example, you can log:

   "A string "+num,str.length >1,str.toUpperCase(),obj

   In this case, the logged message is:

   // str = "test"// num = 42// obj = {attr: "x"}Astring42trueTEST{attr:'x'}

7. PressEnter to activate the breakpoint. A pink icon with two dots appears on top of the line number column.

This example shows a logpoint at line 30 that logs a string and a variable value to theConsole.

Edit line-of-code breakpoints

Use theBreakpoints section to disable, edit, or remove line-of-code breakpoints.

Edit groups of breakpoints

TheBreakpoints section groups the breakpoints by file and orders them by line and column numbers. You can do the following with groups:

• To collapse or expand a group, click its name.
• To enable or disable a group or breakpoint individually, click next to the group or the breakpoint.
• To remove a group, hover over it and click.

This video shows how to collapse groups and disable or enable breakpoints one by one or by groups. When you disable a breakpoint, theSources panel makes its marker next to the line number transparent.

Groups have context menus. In theBreakpoints section, right-click a group and choose:

• Remove all breakpoints in file (group).
• Disable all breakpoints in file.
• Enable all breakpoints in file.
• Remove all breakpoints (in all files).
• Remove other breakpoints (in other groups).

Edit breakpoints

To edit a breakpoint:

• Click next to a breakpoint to enable or disable it. When you disable a breakpoint, theSources panel makes its marker next to the line number transparent.
• Hover over a breakpoint and click to edit and to remove it.

• When editing a breakpoint, change its type from the drop-down list in the inline editor.

  

• Right-click a breakpoint to see its context menu and choose one of the options:

  

  • Reveal location.
  • Edit condition or logpoint.
  • Enable all breakpoints.
  • Disable all breakpoints.
  • Remove breakpoint.
  • Remove other breakpoints (in all files).
  • Remove all breakpoints (in all files).

Watch the video to see various breakpoint edits in action: disable, remove, edit condition, reveal location from the menu, and change type.

Skip breakpoints with 'Never pause here'

Use aNever pause here line-of-code breakpoint to skip pauses that would happen for other reasons. This can be useful when you have turned onexception breakpoints but the debugger keeps stopping on a particularly noisy exception that you are not interested in debugging.

To mute a break location:

1. In theSources panel, open the source file and find the line youdon't want to break on.
2. Right-click the line number in the line number column on the left, next to the statement that causes the break.
3. From the drop-down menu, selectNever pause here. An orange (conditional) breakpoint appears next to the line.

You can also mute breakpoint while the execution is paused. Watch the next video to learn the workflow.

WithNever pause here, you can mute debugger statements and every other breakpoint type except line-of-code breakpoints andEvent listener breakpoints.

Never pause here may fail on a line with multiple statements if the statement that shouldn't pause is different from the statement that causes the pause. Insource mapped code, not every breakpoint location corresponds to the original statement that causes the break.

Additionally, theDebugger pauses on events that happen inweb workers orworklets of any type, including theShared Storage Worklets.

This example shows theDebugger paused on asetTimer event that happened in a service worker.

You can also find a list of event listeners in theElements >Event Listeners pane.

Exception breakpoints

Use exception breakpoints when you want to pause on the line of code that's throwing a caught oruncaught exception. You can pause on both such exceptions independently in any debug session other thanNode.js.

In theBreakpoints section of theSources panel, enable one of the following options or both, then execute the code:

• CheckPause on uncaught exceptions.

  

  In this example, the execution is paused on an uncaught exception.

• CheckPause on caught exceptions.

  

  In this example, the execution is paused on a caught exception.

Exceptions in asynchronous calls

With either or both caught and uncaught checkboxes turned on, theDebugger attempts to pause on the corresponding exceptions in both synchronous and asynchronous calls. In the asynchronous case, theDebugger looks for rejection handlers across promises to determine when to stop.

Caught exceptions and ignored code

WithIgnore List turned on, theDebugger pauses on exceptions caught either in non-ignored frames or passing through such a frame in the call stack.

The next example shows theDebugger paused on a caught exception thrown by the ignoredlibrary.js that passes through non-ignoredmycode.js.

To learn more aboutDebugger behavior in edge cases, test a collection of scenarios on thisdemo page.

Function breakpoints

Calldebug(functionName), wherefunctionName is the function you want to debug, when you want topause whenever a specific function is called. You can insertdebug() into your code (like aconsole.log() statement) or call it from the DevTools Console.debug() is equivalent to settingaline-of-code breakpoint on the first line of the function.

functionsum(a,b){ letresult=a+b;// DevTools pauses on this line. returnresult;}debug(sum);// Pass the function object, not a string.sum();

Make sure the target function is in scope

DevTools throws aReferenceError if the function you want to debug is not in scope.

(function(){ functionhey(){   console.log('hey'); } functionyo(){   console.log('yo'); } debug(yo);// This works. yo();})();debug(hey);// This doesn't work. hey() is out of scope.

Ensuring the target function is in scope can be tricky if you're callingdebug() from the DevToolsConsole. Here's one strategy:

1. Set aline-of-code breakpoint somewhere where the function is in scope.
2. Trigger the breakpoint.
3. Calldebug() in the DevTools Console while the code is still paused on your line-of-codebreakpoint.

Trusted Type breakpoints

TheTrusted Type API provides protection against securityexploits known ascross-site scripting (XSS) attacks.

• CheckSink Violations.

  

  In this example, the execution is paused on a sink violation.

• CheckPolicy Violations.

  

  In this example, the execution is paused on a policy violation. Trusted Type policies are set up usingtrustedTypes.createPolicy.

You can find more information about using the API:

• To further your security aims, visitPrevent DOM-based cross-site scripting vulnerabilities with Trusted Types.
• For debugging, visitImplementing CSP and Trusted Types debugging in Chrome DevTools.