Debugging in the browser

Debugging means pausing the movie

A bug is a moment when the program and your expectation split apart. The browser debugger helps you find that moment by pausing JavaScript while it is running. Once paused, you can read the current line, move one step at a time, and inspect the values the program is actually using.

Earlier lessons used the DevTools console and console.log to print clues. That is still useful. But printing is like asking an actor to shout notes while the play continues. A breakpoint is different: it freezes the scene so you can look around.

Open Chrome or Edge DevTools and choose Sources. In Firefox, the panel is called Debugger. In Safari, use Sources after enabling developer features. The names vary, but the ideas in this lesson are the same.

A breakpoint is a marker you place on code. When JavaScript reaches that spot, DevTools pauses before moving on. In most browsers you set a line breakpoint by opening a file in the debugging panel and clicking the line number.

Useful breakpoint types include:

• Line breakpoint: pause every time a line runs.
• Conditional breakpoint: pause only when an expression is true, such as i === 50 in a loop.
• Logpoint: print a message from that line without pausing and without editing the file.
• Pause on exceptions: stop where an error is thrown. Many browsers can also pause on caught exceptions.
• DOM and event listener breakpoints: pause when a page node changes or an event such as a click fires. These are browser features around JavaScript, not new JavaScript syntax.

1// Line breakpoint: pause whenever this line runs.2total = total + price;3 4// Conditional breakpoint: pause only when this is true.5i === 506 7// Logpoint: print a message without pausing.8"total is", total9 10// Pause on exceptions: stop where an error is thrown.11throw new TypeError("price must be a number");

Conditional breakpoints are especially beginner-friendly in loops. If a list has 100 items and only item 50 is wrong, pausing 50 times is exhausting. A condition such as i === 50 lets the browser skip straight to the interesting case.

JavaScript has a built-in statement named debugger. When DevTools is open, the browser pauses on that line as if you had placed a breakpoint there. When DevTools is closed, browsers normally ignore it and keep running.

This is useful when a file is hard to find in bundled source, or when you want a temporary pause in a small local experiment. It is also easy to forget. Remove debugger; before committing or sharing code.

1function handleDebugClick() {2  const label = "Debug button";3  debugger;4  console.log(label + " finished");5}6 7document.querySelector("button").addEventListener("click", handleDebugClick);

Once execution is paused, the toolbar gives you movement buttons. In Chrome and Edge DevTools, Resume is F8, Step over is F10, Step into is F11, and Step out is Shift + F11. Other browsers show similar buttons, but shortcuts can differ.

1totalCart(items);          // Step into opens totalCart2applyDiscount(total);    // Step over runs it and stays here3return roundPrice(value); // Step out finishes this function

The next replay uses one real buggy program at two granularities. The cart should total 30 and apply a 10 percent discount once, so the right answer is 27. The bug applies the discount twice. Switch between Step into and Step over and notice that the final result is the same real value: 24.3.

1const items = [20, 10];Run2 3function roundPrice(amount) {4  return Math.round(amount * 100) / 100;5}6 7function applyDiscount(amount) {8  const discounted = amount * 0.9;9  return roundPrice(discounted);10}11 12function totalCart(prices) {13  let total = 0;14  for (const price of prices) {15    total = total + price;16  }17  const firstPass = applyDiscount(total);18  const finalTotal = applyDiscount(firstPass);19  return finalTotal;20}21 22console.log(totalCart(items));

The bug is line 18: applyDiscount(firstPass). Step into makes that obvious because you see amount become 27 inside the second helper call. Step over still runs the helper, but it hides the helper’s internal lines and shows only the returned value. Step out would matter if you were already inside roundPrice and wanted to finish that helper and return to applyDiscount.

Pausing is useful because the debugger shows what names mean at that exact moment. The Scope panel usually groups values into sections. Local means variables in the current function. Closure means variables remembered from an outer function; the Closures lesson goes deeper later. Global or Script means top-level values.

A Watch expression is an expression you pin to the debugger, like a gauge on a dashboard. Every time execution pauses, the browser tries to evaluate it using the current values. Good watches are small: subtotal * discountRate, items.length, or total === 27.

1const subtotal = 30;2const discountRate = 0.1;3 4function applyDiscount(amount) {5  const discounted = amount - amount * discountRate;6  return Math.round(discounted * 100) / 100;7}8 9const total = applyDiscount(subtotal);

Debugging is faster when you pick the smallest tool that answers your question. Sort each scenario by the kind of debugger tool you would reach for first.

Where you will use this

Browser debugging is most useful when the code is correct-looking but the values are not. A shopping cart, form validator, quiz score, or button state can all fail because one value changed earlier than you expected.

1const items = [20, 10];2 3function roundPrice(amount) {4  return Math.round(amount * 100) / 100;5}6 7function applyDiscount(amount) {8  const discounted = amount * 0.9;9  return roundPrice(discounted);10}11 12function totalCart(prices) {13  let total = 0;14  for (const price of prices) {15    total = total + price;16  }17  const firstPass = applyDiscount(total);18  const finalTotal = applyDiscount(firstPass);19  return finalTotal;20}21 22console.log(totalCart(items));

A practical debugging routine looks like this:

1. Describe the wrong behavior in one sentence.
2. Set a breakpoint before the value first looks suspicious.
3. Step over trusted helpers; step into helpers that may hide the bug.
4. Read Scope before guessing. Add Watch expressions for values you keep recomputing.
5. Fix the smallest line, then rerun from the start.

Common misconceptions

Pick an answer, read the explanation, and connect it back to the debugging move you would make in DevTools.

Key takeaways

• Breakpoints pause code so you can inspect the exact moment a value changes.
• debugger; is a real temporary pause when DevTools is open; remove it afterward.
• Step over runs a call without opening it. Step into opens it. Step out finishes the current function.
• Scope shows reachable values now; Watch pins expressions you want to recalculate on each pause.
• Use the course replay for learning, and your browser’s DevTools for real debugging.

Up next: Coding style & naming.