Chrome DevTools Breakpoints Are More Than Click-to-Add
Conditional breakpoints, logpoints, and DOM breakpoints solve problems a plain click-to-pause breakpoint can't touch.
A few years into my career, I spent most of a day chasing a bug in a web app's admin panel that only happened after a specific sequence of clicks, on a page with enough traffic that a plain breakpoint — pause every single time this line runs — was useless; I would have hit resume a hundred times before the actual bad state showed up. That's when I actually learned Chrome DevTools has more than one kind of breakpoint.
A conditional breakpoint is the fix for exactly that problem: right-click the line number in the Sources panel, choose "Add conditional breakpoint," and enter an expression. The debugger only pauses when that expression is truthy, so instead of stepping through a hundred irrelevant calls, you can pause only when, say, a specific user ID or an unexpected null shows up in a variable you're watching.
Logpoints solve a different problem: sometimes you don't want execution to stop at all, you just want visibility — the equivalent of a console.log, but without editing the source file, redeploying, or remembering to pull the log statement back out afterward. A logpoint runs your expression and prints it to the console every time that line executes, then execution just continues.
DOM breakpoints are the one I use least often but reach for when the bug is specifically that an element is changing and I can't tell what's touching it. Right-click an element in the Elements panel and you can break on subtree modifications, attribute modifications, or node removal — useful for tracking down which script is quietly deleting or restyling something you didn't expect touched.
The common thread across all three is the same lesson that production bug taught me: a plain breakpoint tells the debugger to stop, full stop, and leaves the "figure out when this actually matters" work to you, clicking resume over and over. Conditional breakpoints, logpoints, and DOM breakpoints move that filtering logic into the debugger itself, which is the difference between finding a bug in minutes and losing an afternoon to it.
All three are documented, with more detail than fits here, in Chrome DevTools' own breakpoints documentation on developer.chrome.com.