Debug JavaScript With Breakpoints in Chrome DevTools: Guide

Your JavaScript does something wrong, and staring at the code is not revealing why. Maybe a total calculates incorrectly. Maybe a variable holds the wrong value. Maybe a function runs when it should not. Beginners often respond by adding dozens of console.log lines and still feeling lost.

There is a better tool built into your browser: breakpoints in Chrome DevTools. A breakpoint pauses your code at an exact line so you can inspect everything at that moment. This beginner guide shows you how to open DevTools, set your first breakpoint, and debug with confidence.

Quick Answer

To debug JavaScript with breakpoints, open your page in Chrome, press F12 to open DevTools, go to the Sources panel, and find your file in the left sidebar. Click a line number in the code to set a breakpoint, then reload the page or trigger the action. Chrome pauses on that line, letting you inspect variable values, step through code line by line, and watch the call stack to find exactly where things go wrong.

What Is a Breakpoint and Why Use One?

A breakpoint tells the browser to stop when execution reaches that line. While paused, the page is frozen. You can read every variable in scope, see which function called this code, and advance line by line.

Compared with console.log, breakpoints give you the full picture without editing code. You see the real state, not the state you guessed and chose to print.

The full feature set is in the Chrome DevTools documentation for debugging JavaScript, but this guide focuses on the small core you need most.

Step 1: Open DevTools and Find Your File

Start with the page open in Chrome and showing the problem area.

1. Press F12 or Ctrl + Shift + I on Windows, or Cmd + Option + I on a Mac, to open DevTools.
2. Click the Sources tab at the top of the DevTools panel.
3. In the left sidebar, browse the file tree to find your JavaScript file. If the tree is crowded, press Ctrl + P and type part of the file name to open it instantly.
4. Click the file so its code appears in the center editor.

Note the layout: file list on the left, code in the middle, and debugging panels like Scope and Call Stack on the right.

A Note on Minified or Bundled Code

If framework code looks compressed, click the pretty-print button, shown as { }, to reformat it. Source maps usually let DevTools show your original files instead.

Step 2: Set Your First Breakpoint

Setting a breakpoint takes one click. In the code editor, click the line number gutter next to the line where you want execution to pause. A blue marker appears. That line is now armed.

Place it just before the behavior goes wrong, at a line you are sure runs, such as the first line of a suspicious function. Avoid tight loops until you learn conditional breakpoints below.

Now trigger the code by reloading or performing the action. Chrome highlights your line and pauses. The page is frozen until you resume. This pause is where debugging begins.

Step 3: Inspect Variables While Paused

While paused, your first job is simply to look. Several inspection tools are available:

• Hover over a variable in the code editor to see its current value in a small popup.
• Scope panel on the right lists local and global variables in scope at this line, with their values. Expand objects and arrays to inspect their contents.
• Watch panel lets you add any expression, such as items.length or user.name, and see its live value as you step.
• Console while paused evaluates expressions in the paused context. Type a variable name and press Enter to see its value, or test a condition like total > 100.

Ask: do the values match what you expected? The first surprising value is usually within a line or two of the real bug.

Read the Call Stack

The Call Stack panel shows the chain of calls that led to this line. Clicking an entry jumps to that call site. This answers “how did the code get here?” when a function is called from several places.

Step 4: Step Through the Code

Inspection tells you the state now. Stepping lets you watch it change. The stepping controls sit at the top of the right panel in the Sources tab:

1. Resume (play icon or F8): continue running until the next breakpoint.
2. Step over (F10): run the current line and pause on the next one, without entering functions called on this line.
3. Step into (F11): move into the function called on the current line, so you can debug inside it.
4. Step out (Shift + F11): finish the current function and pause back in its caller.

A good routine: pause, check values, then step over line by line, watching Scope after each step. The moment a value becomes wrong, the line you just ran is the culprit or feeds it.

The official walkthrough of these controls appears in the Chrome DevTools guide to pausing code with breakpoints, which is worth bookmarking once the basics feel familiar.

Step 5: Use Smarter Breakpoint Types

Plain line breakpoints are just the start. Three other types solve problems beginners meet quickly.

Conditional Breakpoints

Right-click a line number and choose “Add conditional breakpoint”. Enter a condition like i === 50 or user.id === 7. Chrome now pauses only when the condition is true. This is essential in loops and in handlers that fire for many items, where pausing every time would take forever.

DOM and Event Breakpoints

The Event Listener Breakpoints section lets you pause on event categories like mouse clicks. This helps when you do not know which code runs first, as in the problems covered by our guide on why a React app shows a blank white page and how to trace the failure.

The debugger Statement

Write debugger; on its own line in your code and Chrome pauses there when DevTools is open. Remove these statements before publishing your work.

A Complete Beginner Debugging Session

Let us tie it together with a simple scenario. A shopping cart total shows the wrong amount. Here is a calm routine:

1. Open DevTools, find the file with the total calculation, and set a breakpoint on the line that adds an item’s price to the total.
2. Click the page’s add-to-cart button. Chrome pauses before the addition runs.
3. Hover over the price and quantity variables. Suppose quantity shows as the string "2" instead of the number 2. That mismatch explains wrong math.
4. Check the Call Stack to see where quantity came from, step back to that code, and you find the value was read from an input field without converting it to a number.
5. Fix the input handling, reload, and repeat the click to confirm the total is now correct.

Notice: no guessing. You paused, observed, and followed the bad value to its source. That loop is the whole skill.

Common Mistakes and Useful Tips

• DevTools closed during a debugger statement: the debugger; statement only pauses when DevTools is open. Keep the panel open during your session.
• Debugging the cached old file: if your breakpoints land on odd lines or code looks outdated, hard-refresh the page so Chrome loads your latest files.
• Too many breakpoints: disable breakpoints temporarily with the deactivate-breakpoints button instead of deleting them, so you can focus on one area at a time.
• Forgetting the page is paused: a frozen page often just means execution is sitting on your breakpoint. Resume with F8 before assuming the site crashed.
• Pausing on every loop pass: switch to a conditional breakpoint instead of pressing resume fifty times. Your patience will thank you.
• Editing code in Sources and losing track: you can test small edits in DevTools, but save real fixes in your actual project files, then reload and verify the fix there.

Tip: note the expected value, the actual value, and the line where they first differed. That note often contains the fix.

Conclusion

Breakpoints turn debugging from guessing into observing. Open the Sources panel, click a line number, trigger the action, inspect the values, and step line by line until a value surprises you. That surprise marks your bug. Add conditional breakpoints and the call stack as you grow, and you will have the same core workflow that professional developers use every day.

Frequently Asked Questions

Why does my page freeze when I set a breakpoint?

The freeze is the breakpoint working correctly. Chrome has paused your JavaScript mid-execution, so the page cannot respond until you resume. Use the Resume button or press F8 to continue, or step through line by line if you want to keep inspecting.

How do I remove or disable a breakpoint?

Click the blue marker on the line number again to remove that breakpoint. To disable all breakpoints without deleting them, use the deactivate-breakpoints control in the Sources panel. The Breakpoints list in the right sidebar also lets you toggle each one individually.

What is the difference between step over and step into?

Step over runs the current line as a single unit, including any function it calls, and pauses on the next line. Step into enters the function called on the current line so you can debug inside it. Use step over to move quickly, and step into when you suspect the called function itself.

Can I change a variable’s value while paused?

Yes. While paused, you can double-click a value in the Scope panel to edit it, or type an assignment in the console, such as setting a variable to a test value. This lets you test a hypothesis about the fix before you change your real code.

Why do my breakpoints disappear after reloading the page?

Breakpoints normally persist, but they can be lost if the file URL changes between loads, for example when build tools add changing hashes to file names, or if you are debugging a different copy of the file than you think. Check the file name in Sources and re-set the breakpoint on the file actually being served.