Browser DevTools

Every real browser ships with a full set of tools for inspecting and debugging the page you're looking at, built directly into the browser, free, with no setup. If you've been reading this course wondering "how would I check that a rule is actually applying" or "how do I see the real computed size of this box" — this is the answer, and it's worth learning early, because you'll reach for it in nearly every layout problem from here on.

Menu paths and exact panel names differ slightly between browsers, so this lesson describes behaviour that's consistent across all of them, phrased generically ("in most Chromium-based browsers", "in Firefox") rather than one exact click path.

Opening devtools

• Keyboard shortcut — usually F12, or Cmd+Option+I on macOS / Ctrl+Shift+I on Windows/Linux, across most Chromium-based browsers (Chrome, Edge, Brave) and Firefox. Safari requires enabling the Develop menu first, in Safari's settings.
• Right-click → Inspect — right-clicking any element on a page and choosing "Inspect" (or "Inspect Element") usually opens devtools already focused on that exact element, which is often faster than opening devtools generally and then hunting for the element afterward.

Once open, devtools is a panel of its own tabs — Elements/Inspector, Console, Network, and several more. This lesson focuses on the two most relevant to CSS: the Elements/Inspector panel and its Styles/Computed sub-panels.

The Elements/Inspector panel: live-editing the DOM

This panel shows the page's actual DOM tree — not your original HTML source file, but the live, current structure the browser is rendering right now, which can differ from the source if JavaScript has modified it since the page loaded.

You can double-click almost anything here and edit it directly: change a tag's text content, add or remove an attribute, even drag-and-drop whole elements to reorder them. The change applies instantly and you see the result rendered on the page in real time.

This is a genuinely important point to internalize: these edits are temporary. They live only in the browser's in-memory copy of the page for this one session. Reload the page, and every edit vanishes, back to whatever the actual HTML file (or server response) says. This makes it an excellent debugging and experimentation technique — try three different heading texts, test what a layout looks like with an extra <div>, remove an element to see what breaks — without any risk of accidentally damaging your real files. It is not a way to actually publish a change; for that, you still have to edit the real source file.

The Styles pane: watching the cascade in real life

Selecting an element in the Elements/Inspector panel shows, alongside it, a Styles pane listing every CSS rule that matches that element, from every stylesheet on the page, in cascade order.

This is the earlier cascade lesson made directly visible. When two rules conflict on the same property, the rule that actually applies is shown in full, and the rule(s) that lost — overridden by higher specificity or later source order — are shown struck through, so you can see at a glance not just what styling won, but what it beat. If a rule you wrote isn't taking effect, this is usually the fastest way to find out why: open the Styles pane, find your rule, and see whether it's crossed out and, if so, which rule beat it.

Most browsers also let you toggle individual declarations on and off with a checkbox right in this pane, and edit a value directly (click a color or a number and adjust it) to see the effect live — another purely temporary, session-only change, exactly like editing the DOM tree.

The box model diagram

Also in or near the Styles pane, devtools draws a small labelled diagram of the selected element's box model — the same content/padding/border/margin structure from the box-model lesson, but now showing the actual current pixel values for this specific element, computed after every CSS rule has been applied:

• The innermost box is the content area's actual rendered width and height.
• The next ring out is padding, with its resolved pixel value on each side.
• Then border.
• Then margin, on the outside.

This is often the single fastest way to answer "why is this bigger/smaller than I expected" — rather than mentally recalculating box-sizing and padding by hand, the diagram just tells you the resolved numbers directly.

The Computed tab: the final answer after the cascade

The Styles pane shows every rule that could apply, in order, with winners and losers. The Computed tab (a separate tab, usually right next to Styles) shows something different: for any given property, the single final value the browser actually used, after the entire cascade has been resolved.

This matters because a property's final value sometimes isn't written literally anywhere in your CSS — it might be inherited from a distant ancestor, or be a browser default you never explicitly set. If you want to know "what is this element's actual line-height right now," regardless of which of several rules produced it, the Computed tab is the direct, unambiguous answer, without you having to manually trace the cascade yourself.

The responsive/device toolbar

Every major browser's devtools includes a toggle (often an icon that looks like a phone and tablet side by side) that switches the page into a resizable, simulated-viewport mode — letting you test how a layout responds at a range of widths without physically resizing your actual browser window, and often with presets for common device dimensions plus a fully custom width/height input.

This is exactly what makes the media-query and mobile-first lessons in this course practical to actually test: rather than manually dragging a window's edge and guessing at pixel widths, the device toolbar shows you the current simulated width directly and lets you type in an exact number to check a specific breakpoint.

1. Step 1

   Open devtools

   F12, or right-click an element and choose Inspect, in most browsers.

2. Step 2

   Select an element

   Click it on the page, or click it directly in the Elements/Inspector tree.

3. Step 3

   Read the Styles pane

   See every matching rule, with overridden ones struck through — the cascade made visible.

4. Step 4

   Check Computed

   See the single final resolved value for any property, regardless of which rule produced it.

5. Step 5

   Resize with the device toolbar

   Test the layout at any viewport width without touching your real window size.

Try it yourself

Open real devtools on the markup below (right-click the rendered output and choose Inspect, or select it and press your browser's devtools shortcut). Try: selecting the <p> and checking whether .intro's color rule or the plain p rule wins in the Styles pane; editing the heading's text directly in the Elements tree; and checking the box model diagram for .card to confirm its padding and computed width.

What to remember

• Open devtools with F12 (or the platform equivalent) or right-click → Inspect, in any major browser.
• The Elements/Inspector panel shows the live DOM and lets you edit it directly — genuinely useful for experimenting, but every edit vanishes on reload.
• The Styles pane lists every matching rule in cascade order, with overridden rules shown struck through — the fastest way to see why a rule you wrote isn't winning.
• The box model diagram shows an element's actual resolved content/padding/border/margin pixel values.
• The Computed tab shows the single final value of any property after the whole cascade has resolved, even if that value isn't written literally anywhere in your CSS.
• The responsive/device toolbar simulates any viewport width, which is how you actually test the media queries and breakpoints from earlier in this course.