The devtools tour

You wrote the code. The page loads. Something's wrong — a button doesn't fire, an image is huge, the page hitches when you scroll. You can keep adding console.log until the answer falls out, or you can open devtools and look directly at what's happening. Devtools is a small set of panels, and most people use one and a half of them.

This lesson is a guided tour. You'll meet each panel, learn what it shows, and — more importantly — learn the moment you'd reach for it. Knowing a panel exists isn't useful; knowing when to open it is.

We'll use Chrome DevTools as the reference. Firefox and Safari have the same panels under slightly different names, with the same purpose.

Opening devtools

Three ways to open devtools, all worth knowing:

• Keyboard: F12, or Ctrl+Shift+I on Windows/Linux, Cmd+Option+I on macOS.
• Right-click an element on the page → Inspect. This jumps straight to the Elements panel with that element selected. The fastest path when you're chasing a layout bug.
• Right-click → Inspect on a specific input or button when you want to know its exact attributes, IDs, or class names.

The panel names sit across the top: Elements, Console, Sources, Network, Performance, Memory, Application — and a handful of others. The order varies by browser version. The first six are where almost all the work happens.

Elements

The Elements panel shows the live DOM tree — not your HTML source, but the page as it exists in memory right now. If JavaScript added a <div>, it's here. If a script removed one, it isn't.

Hover any node and the browser highlights it on the page with a colored overlay showing margin, border, padding, and content — the box model in real time.

The right side splits into tabs:

• Styles — every CSS rule applied to the selected element, in cascade order. Strikethrough text means a rule was overridden. You can edit any value live and the page updates instantly.
• Computed — the resolved final value of every property. Use this when Styles shows three competing rules and you want to know which one actually won.
• Layout — toggle grid and flex overlays, see margin/padding diagrams.
• Event Listeners — what JavaScript handlers are attached to this element.

When to reach for Elements: a button is in the wrong place, text is the wrong color, an image isn't showing up, you want to test a CSS change before you commit it.

/* Click the property in the Styles panel and type a new value.
 The page updates immediately — no save, no reload.   */
.button {
background: salmon;     /* edited live, vanishes on reload */
padding: 12px 18px;
}

Edits in the Styles panel are temporary — they vanish the moment you refresh. The Elements panel is for exploring, not for editing files. When you find the right value, copy it into your real CSS file.

Console

The Console is two things in one panel: a log viewer and a JavaScript REPL — meaning a place where you can type JavaScript and run it against the page right now.

The log side shows everything console.log, console.warn, and console.error have produced, plus errors the browser caught on its own (unhandled exceptions, failed network requests, security warnings).

The REPL side accepts any JavaScript. Type document.title, hit enter, and it returns the title. Type document.querySelector('button').click() and the button on the page is clicked.

A handful of conveniences worth knowing:

• $0 is whatever element you most recently selected in Elements. So you can click a button in Elements, switch to Console, and type $0.click() to fire it.
• $('selector') is a shortcut for document.querySelector — same thing, fewer keystrokes. $$('selector') is querySelectorAll.
• copy(value) copies anything to the clipboard, including objects (it serializes them to JSON).

When to reach for Console: an error appeared and you want to read its stack trace, you want to inspect what a variable is right now, you want to test a one-liner before putting it in your code.

The next lesson goes deep on the methods beyond log. For this tour: Console is your inspection workbench.

Sources

The Sources panel is a code editor with magic powers. The left column lists every file the browser has loaded — your own scripts, third-party libraries, sourcemapped originals. Click a file to open it, set a breakpoint by clicking a line number, and the next time that line runs, the page pauses. You can step through, peek at variables, and figure out what the code is actually doing instead of what you think it's doing.

Three full lessons in this course unpack what Sources can do (lessons 2, 4, and 6). For now, the headline:

• It's where you debug code with breakpoints.
• It's where you verify your source maps are working — original filenames appear in the file tree if maps are loaded.
• It includes a Snippets feature for saving little JavaScript scratch programs you want to run on any page.

When to reach for Sources: when console.log isn't enough — when you need to pause execution and look around.

Network

Network shows every HTTP request the page makes, in the order they happened, with sizes and timings. The waterfall on the right shows when each request started, how long DNS took, how long the server took to respond, and how long the bytes took to arrive.

You can filter by type — XHR/fetch (your API calls), JS, CSS, Img, Doc — to focus on what matters.

A request row tells you a lot:

• Status — 200 means OK, 304 is a cache hit, 404 is not found, 5xx is the server's fault.
• Type — what the browser thinks this is (script, stylesheet, image).
• Size — bytes over the wire and bytes after decompression.
• Time — the total duration of the request.

Click a row to see headers, the response body, the request payload, and a per-request waterfall.

When to reach for Network: an API request isn't returning what you expect, the page is loading slowly, an image isn't appearing (is it a 404 or something else?), you want to know how big a third-party script actually is.

Performance

The Performance panel records what the browser was doing, millisecond by millisecond, while you interacted with the page. Click record, do the slow thing, click stop, and it draws you a flamegraph.

A flamegraph is a stacked bar chart of function calls over time — the top bar is whatever was running, the bars beneath it show what called that function, and the bars beneath those show what called those. Wide bars mean slow. Skinny ones flew by.

It's the panel you open when the page is janky — scrolling stutters, an animation drops frames, clicking a button takes a second to respond. The whole of lesson 8 is about reading this panel; for the tour, just know it exists and that it answers the question "what was the browser actually doing during that bad moment?"

Memory

The Memory panel takes snapshots of every JavaScript object the page is holding onto, lets you compare snapshots, and helps you find leaks — objects the code keeps alive after they should have been thrown away.

The most common kind of leak in frontend code is a detached DOM node — an element the JavaScript still references after the page removed it from the DOM. Lesson 7 walks through this in detail.

When to reach for Memory: the page gets slower the longer it stays open, an SPA's memory use climbs every time you navigate, you're chasing a leak.

Application

Application is the storage panel. It shows what your page has stored in: cookies, localStorage, sessionStorage, IndexedDB, the Cache API, service workers, and a few more.

When to reach for Application: a cookie isn't being set the way you expect, you want to clear localStorage to test a fresh-user experience, you want to see what the service worker is caching.

This panel doesn't get its own lesson in this course — it's a inspector for browser storage rather than a debugging surface — but you should know it's where to look when state survives a reload that you didn't put in JavaScript memory.