DevTools shipped with the browser. Most developers use maybe 20% of what’s there. The remaining 80% includes tools that can cut hours from a debugging session, expose layout bugs that would otherwise take days to isolate, and surface accessibility problems before a screen reader user reports them. What follows is a tour of the features that reward closer attention — with an emphasis on capabilities that are easy to miss, including the ones most relevant to a broader cross-browser testing workflow rather than single-browser debugging alone.

The Elements Panel Beyond DOM Inspection

Everyone knows how to right-click and inspect. The panel that opens — the Elements panel in Chrome and Edge, the Inspector in Firefox — does far more than show you the DOM tree.

Computed Styles and the Box Model Visualizer

The Computed sub-panel resolves every CSS property to its final value after cascade, inheritance, and specificity have been applied. Filter the list to show only properties with non-inherited values to cut the noise. Click any computed value and DevTools jumps to the rule that produced it, including the source file and line number.

The box model diagram at the top of the Computed panel is interactive in Chrome: hover any region — content, padding, border, margin — and the browser highlights that exact layer on the page. More importantly, it displays the computed pixel dimensions for each layer. When an element’s effective size differs from what your CSS suggests, the box model diagram is where the discrepancy becomes visible immediately.

Firefox’s box model display adds one useful detail: it renders negative margins in a distinct color, which Chrome does not.

Cascade Visualization in Chrome

Chrome 106 shipped a significant upgrade to the Styles sub-panel: cascade layer visualization. When your stylesheet uses @layer, DevTools now shows which layer each rule belongs to and — crucially — renders crossed-out rules with a tooltip explaining exactly why a declaration lost. The tooltip distinguishes between “overridden by a later rule in the same layer,” “overridden by a higher-priority layer,” and “overridden by a higher specificity selector.” This replaces the guesswork that previously made debugging layered stylesheets painful.

For projects using the CSS Cascade Layers specification, this feature alone justifies keeping Chrome in your debugging rotation even if your primary development environment is Firefox.

The Accessibility Tree

This is the most underused view in DevTools. In Chrome, open the Elements panel, then in the right-side sub-panels find Accessibility. It shows the accessibility tree for the selected element: its role, its computed accessible name, its properties (aria-expanded, aria-required, aria-label, etc.), and its position in the tree relative to siblings and ancestors.

Switch to the dedicated Accessibility panel (available via the three-dot menu → More tools → Accessibility in Chrome) to see the full page accessibility tree rendered as a hierarchical outline. This is what assistive technology actually reads — not the DOM, not the visual layout. Structural problems that are invisible in the DOM become obvious here: a heading level that skips from h2 to h4, a button with no accessible name, a <div> acting as an interactive control without a role assignment.

Firefox DevTools has offered a comparable Accessibility panel for longer, and it includes a Show tabbing order feature that overlays numbered badges on all focusable elements in tab sequence. Chrome added equivalent tab order visualization in 2023 under Accessibility → Enable full-page accessibility tree → Tab order.

For deeper context on how semantic structure feeds into the accessibility tree, the HTML semantics article covers the relationship between element choice and computed role.

CSS Editing Directly in DevTools

The Styles panel isn’t read-only. You can click any property value and edit it live. More useful: click the empty space after any selector to add a new property declaration. Changes persist until you reload — or until you use Changes (More tools → Changes) to get a diff of every edit made during the session, which you can copy back into your source files.

Color values render with a swatch. Click the swatch to open the color picker, which in Chrome includes an eyedropper tool and an option to switch the color model (hex, rgb, hsl, oklch). The picker also displays contrast ratio against the element’s background when a text color is selected — a direct connection between your editing workflow and accessibility compliance.

One frequently overlooked feature: holding Shift while clicking the color swatch cycles through color formats without opening the picker. Fast when you need to convert a hex value to hsl for a custom property.

The Performance Panel: Reading the Flame Chart

The Performance panel records a trace of browser activity — JavaScript execution, style recalculation, layout, paint, and compositing — and renders it as a flame chart on a timeline.

Main Thread Activity

The main thread section of the flame chart shows call stacks rendered as stacked colored bars. Wider bars indicate longer execution. The color coding is consistent: yellow for JavaScript, purple for rendering (style recalc and layout), green for painting. A spike that’s mostly purple suggests your CSS is triggering expensive recalculations — often because a property that forces layout (like width, height, or top) is being animated instead of a composited property like transform or opacity.

Click any bar to select it. The Summary panel below breaks down the selected task’s time by category. For a long task (any task exceeding 50ms on the main thread), DevTools highlights it in red and flags it as a Long Task — the metric that feeds Total Blocking Time in Lighthouse.

CLS in the Experience Section

The Experience lane in Chrome’s Performance panel shows Cumulative Layout Shift events as red markers on the timeline. Click one to see exactly which elements shifted, by how much, and what caused them. This is far more actionable than a CLS score from Lighthouse, which tells you there’s a problem but not which elements moved or when.

Common culprits that show up clearly here: images without explicit width and height attributes, late-loading web fonts that cause text reflow, and injected ad slots that push content down. The Sources panel integrated view lets you jump from the shift to the responsible CSS rule.

Firefox has a Performance panel with a flame chart as well, though it uses different terminology. The “Marker” timeline includes paint events and garbage collection markers that Chrome’s equivalent sometimes omits, making it useful for diagnosing memory-adjacent performance issues.

The Network Panel: More Than a Waterfall

The Network panel’s waterfall is familiar. Less familiar are the features layered on top of it.

Filtering and the Priority Column

The filter bar accepts file type shortcuts — JS, CSS, Img, Media, Font, Doc, WS, Wasm — but also accepts free-text strings, negative filters using the - prefix, and domain: scoped searches. Filtering to -domain:yourdomain.com shows every third-party request your page makes, which is useful for auditing external dependencies.

Enable the Priority column (right-click any column header to toggle it) to see how the browser has ranked each resource for loading. Resources the browser considers low priority load last, even if they appear early in the waterfall. A font file marked “Low” when you expected “Highest” indicates the browser’s preload scanner didn’t encounter your <link rel="preload"> hint early enough — or that the hint is missing entirely.

For a detailed treatment of how font loading priority interacts with rendering, the web fonts guide covers preload strategies and font-display tradeoffs.

Timing Breakdown

Click any network request and open the Timing tab. It breaks the request into phases: Queued, Stalled, DNS Lookup, Initial Connection, SSL, Request Sent, Waiting (TTFB), and Content Download. A large “Waiting” value points to a slow server response or a Time to First Byte problem on the backend. A large “Stalled” value typically means the browser queued the request because the maximum concurrent connection limit for that origin was already reached — which often indicates too many requests to the same host.

The initiator column in the main request list traces each request back to the JavaScript call or HTML element that triggered it, including the file and line number. For third-party scripts that spawn cascades of additional requests, this trace is the fastest path to identifying the source.

Lighthouse: What the Scores Actually Mean

Lighthouse runs inside DevTools under the dedicated Lighthouse panel. It audits Performance, Accessibility, Best Practices, and SEO, then generates a scored report with specific failing items.

The Performance score is a weighted composite of six metrics: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, Speed Index, and Time to Interactive. The weights change periodically — the Lighthouse scoring calculator shows current weights and lets you model how improving a single metric would affect the composite score.

A few things worth understanding about Lighthouse scores:

They are simulated. The default throttling profile simulates a mid-tier mobile device on a 4G connection. Your score on a fast laptop over a fiber connection will look nothing like the Lighthouse result. This is intentional — it surfaces issues that real-world users on constrained devices encounter.

The Accessibility score is not a complete audit. Lighthouse catches the automatable subset of WCAG issues: contrast ratios below 4.5:1, images without alt text, form inputs without labels, duplicate IDs. It cannot assess keyboard navigability, focus management, meaningful reading order, or the accuracy of aria labels. A perfect Lighthouse Accessibility score does not mean the page is accessible.

Best Practices catches real bugs. The Best Practices audit flags deprecated APIs, browser console errors, insecure cross-origin requests, and missing HTTPS for resource loads. These are production-quality issues, not stylistic preferences.

The Accessibility Panel: Contrast and Tab Order

Return to the dedicated Accessibility panel for two features that belong in a standard review workflow.

Contrast checking is embedded in the Elements panel color picker (click a text element’s color swatch), but the Accessibility panel’s contrast checker runs against the computed background — factoring in opacity and layered backgrounds — rather than just the declared color values. This distinction matters when you have semi-transparent overlays or gradient backgrounds where the actual rendered contrast differs from what the CSS values suggest at face value.

Tab order visualization (Chrome: Enable full-page accessibility tree, then select Tab order) overlays numbered badges across the page in focus sequence. The sequence should follow a logical reading order and should not jump unpredictably between regions. When a keyboard user tabs through a modal dialog and focus escapes to content behind the overlay, tab order visualization shows the problem instantly — the badge sequence passes through elements that should not be reachable.

The WCAG 2.1 Success Criterion 2.4.3 (Focus Order) requires that focus order preserve meaning and operability. Tab order visualization is the fastest automated check for this criterion during development.

DevTools is not static. Chrome, Firefox, and Safari all ship panel updates in their regular release cycles. The Chrome DevTools release notes publish with each stable release. Firefox DevTools changes appear in the Firefox Developer Experience blog. Checking these periodically surfaces capabilities — like cascade layer visualization or the Experience panel — well before they appear in tutorials or secondary documentation.

The tools are already installed. The gap is familiarity.