Browser DevTools & Debugging

What is it?

Every major browser ships with a set of built-in tools, usually opened with a keyboard shortcut or a right-click "Inspect," collectively called DevTools. They exist because a webpage's visible output often isn't enough to understand or fix a problem — you need to see the actual structure underneath, watch code run, inspect network traffic, or catch errors as they happen.

A few panels come up constantly. The Elements panel shows the live DOM tree (not the original HTML source) along with the computed CSS for whatever element you select, and lets you edit either on the fly to experiment. The Console panel shows messages logged by JavaScript, reports errors and warnings as they occur, and doubles as a live JavaScript prompt where you can run code directly against the current page. The Network panel lists every request the page has made — what was requested, how long it took, what came back — which is usually the first place to look when something isn't loading or is loading slowly. The Sources panel shows the actual JavaScript files running on the page and lets you set breakpoints — points where execution pauses so you can inspect variables and step through code line by line, rather than guessing what's happening from logs alone.

Explain like I'm 10

DevTools is like popping the hood of a car instead of just looking at the dashboard — the dashboard (the rendered page) tells you the car is running, but the hood lets you see exactly which part is actually misbehaving.

Examples

Inspecting and editing the live DOM

// In the Elements panel, selecting an element shows
// its live HTML and the CSS rules currently applied to it.
// Editing text or a style there updates the page instantly,
// without changing any actual file on disk.

This is a fast way to test a visual tweak — try a new color or margin live in the browser — before actually writing it into a CSS file, since it's the live DOM being edited, not the source.

Setting a breakpoint in Sources

function calculateTotal(items) {
  let total = 0;
  for (const item of items) {
    total += item.price; // <- breakpoint set on this line
  }
  return total;
}

Setting a breakpoint on the marked line pauses execution every time that line is about to run, letting you inspect the current values of total and item right there, rather than sprinkling console.log statements throughout the code.

How it works

DevTools is built directly into the browser and has privileged access to the page's internals: it can read the live DOM and its computed styles directly (Elements), tap into the JavaScript engine to log messages, catch errors, and run arbitrary code in the page's context (Console), observe every network request the page's engine makes (Network), and pause the JavaScript engine's execution at specific lines (Sources). None of this requires the page itself to include any special debugging code — the browser exposes it for every page by default.

Why does it exist?

DevTools exists because "look at the rendered page" isn't nearly enough information to build or fix anything nontrivial — you need visibility into structure, styling, network activity, and code execution that never shows up in the rendered output itself. Having this built into every browser, available on any page, makes debugging a normal part of using the web platform rather than something requiring separate, specialized tools.

When to use it

Reach for the Elements panel when something looks visually wrong and you need to see the actual applied styles. Reach for Console when checking for errors or quickly testing a snippet of code. Reach for Network when something isn't loading, is loading slowly, or you need to inspect what a request actually sent or received. Reach for Sources and breakpoints when you need to understand exactly what a piece of JavaScript is doing step by step, rather than guessing from behavior alone.

When not to use it

DevTools is a debugging and inspection tool, not a way to permanently change a site — anything edited live in the Elements or Sources panel disappears the moment the page reloads, since none of it touches actual source files. For understanding intended, permanent behavior, reading the actual source code remains the source of truth.

Common mistakes

• Editing something in the Elements panel and expecting the change to persist after a page reload, when live edits vanish on refresh.

• Ignoring the Network panel when debugging a 'blank page' or missing-data issue, when a failed or slow request is often the actual cause.

• Relying only on scattered console.log statements for a tricky bug instead of using a breakpoint to pause and inspect state directly.

Practice exercises

1. Easy:

   Open DevTools on any webpage, select an element in the Elements panel, and identify one CSS rule currently applied to it.

2. Medium:

   Open the Network panel, reload a page, and find the single largest resource that was downloaded.

3. Hard:

   Set a breakpoint inside a JavaScript function on a real page, trigger it, and step through the code line by line while watching a variable's value change.

Interview questions

What's the difference between the Elements panel and viewing a page's HTML source?

The Elements panel shows the live, current DOM (which may have been changed by JavaScript since the page loaded), while 'view source' shows the original, static HTML as it was first sent by the server.

What is a breakpoint, and why use one instead of console.log?

A breakpoint pauses JavaScript execution at a specific line so you can inspect all current variable values and step through code, which is often faster and more thorough than adding and removing scattered log statements.

When would you check the Network panel while debugging?

Whenever something isn't appearing, is loading slowly, or you need to verify exactly what data a request sent or received — it's the primary place to see all network activity a page has triggered.