Chrome Developer Tools: A Practical Guide to Every DevTools Panel (2026)

Chrome Developer Tools (Chrome DevTools) is the set of web debugging tools built into Google Chrome. It lets you inspect and edit a page’s HTML and CSS, run JavaScript in a console, pause and step through code, watch every network request, measure performance and Core Web Vitals, and look at storage such as cookies and local storage. Open it with F12, Ctrl+Shift+I on Windows and Linux, or Cmd+Option+I on a Mac.

This guide walks through each DevTools panel with what it’s for and the features worth knowing, plus the shortcuts and Console commands that save the most time. The screenshots were taken in October 2026 with the Chromium DevTools front end (the same DevTools Chrome ships) inspecting a small demo shop page I built for this post, and every Console command shown was run there. Edge, Brave, Opera and other Chromium browsers use the same DevTools, so almost all of this applies to them too.

How to Open Chrome DevTools

DevTools opens docked to the side or bottom of the window; use the ⋮ menu inside DevTools to change the dock position or open it in a separate window. Panels are tabs along the top, and pressing Esc opens the drawer at the bottom, where you can keep the Console visible while working in another panel.

The Command Menu

Press Ctrl+Shift+P (Cmd+Shift+P on a Mac) to open the Command Menu, which runs any DevTools command by name: “Show Network”, “Disable JavaScript”, “Capture full size screenshot”, “Emulate CSS prefers-color-scheme: dark”, “Clear site data” and hundreds more. It’s the fastest way to find a feature you don’t know the location of.

The DevTools Panels at a Glance

More tools, such as Rendering, Sensors, Coverage, Animations and Network conditions, live in the drawer; find them through the Command Menu or the ⋮ → More tools menu.

Elements Panel: Inspect and Edit HTML and CSS

The left side shows the live DOM tree (not the original HTML source; see how the DOM tree works), and the right side shows the selected element’s styles. What you can do:

• Edit anything live. Double-click a tag, attribute or text to change it, drag nodes to reorder them, or right-click → Edit as HTML. Press H to hide an element and Delete to remove it.
• Change CSS. Click a value in Styles to edit it (arrow keys nudge numbers), click a checkbox to disable a declaration, or click inside a rule to add a new one. The file and line link shows where each rule came from, and crossed-out declarations are overridden.
• See the final values. The Computed tab lists the value the browser actually used for every property and which rule won.
• Read the box model. The diagram shows content, padding, border and margin sizes, and hovering an element on the page highlights each area.
• Force a state. Click :hov to apply :hover, :focus, :active or :visited so you can style it without keeping the mouse in place.
• Debug layouts. Click a grid or flex badge to draw an overlay with lines, gaps and areas; the Layout tab lists all grid and flex containers on the page.
• Check accessibility. The Accessibility tab shows an element’s computed name and role, and color pickers in Styles show contrast ratios.

Changes you make here are temporary and disappear on reload; copy them back to your code or use Workspaces or Local Overrides (see the Sources panel) to keep them.

Console Panel: Logs, Errors and a JavaScript Prompt

The Console shows messages logged by the page and lets you run JavaScript in the page’s context. Beyond console.log, these methods make output easier to read:

console.table(products);              // array of objects as a sortable table
console.error('Payment failed', err);  // red, with a stack trace
console.warn('Deprecated option');     // yellow
console.group('Checkout'); /* ... */ console.groupEnd();
console.time('render'); /* ... */ console.timeEnd('render');   // render: 12.3 ms
console.assert(total > 0, 'Total should be positive');         // logs only when false
console.count('click');                                         // click: 1, click: 2, ...

Console utilities only available in DevTools

The Console also has built-in helpers that don’t exist in normal page code. I ran these against the demo shop:

Two more Console features: the eye icon creates a live expression that updates continuously (handy for document.activeElement), and the filter box and level menu (Errors, Warnings, Info, Verbose) cut noise on busy pages. Clear the Console with Ctrl+L, or Cmd+K on a Mac.

Sources Panel: Debug JavaScript

Logging is useful, but pausing the code and looking at the real values is usually faster. The Sources panel shows the page’s files, and the debugger sidebar on the right shows variables in Scope, the Call Stack, Watch expressions and all breakpoints.

While paused, step with F10 (step over), F11 (step into), Shift+F11 (step out) and F8 (resume); hover any variable to see its value. Other Sources features worth knowing:

• Pretty print (the {} button) formats minified code, and source maps show your original TypeScript or JSX instead of the bundle.
• Ignore list hides framework and library code from stepping and the call stack (right-click a file → Add script to ignore list).
• Local Overrides save your edits to a local folder and serve them instead of the network version, even on production sites, which is great for testing a CSS or JS fix.
• Workspaces connect DevTools to your project folder so edits in DevTools are saved to your source files.
• Snippets store reusable scripts you can run on any page.
• Search all files with Ctrl+Shift+F (Cmd+Option+F), and open a file by name with Ctrl+P (Cmd+P).

See the official guide to breakpoint types for more detail.

Network Panel: Every Request the Page Makes

The Network panel records requests while it’s open, so open it and reload the page. Click a request to see its Headers, Payload (what was sent), Preview and Response (what came back), Cookies and Timing, which breaks the time into queueing, DNS, connection, waiting for the server (time to first byte) and download. If HTTP basics are new to you, start with what an HTTP request is.

• Filter by type (Fetch/XHR, Doc, JS, CSS, Img), by text, or with properties such as status-code:404, domain: or larger-than:100k.
• Disable cache to see what a first-time visitor downloads, and Preserve log to keep requests across page loads and redirects.
• Throttle the connection to presets such as “Slow 4G” or “3G” to test slow networks.
• Block requests (right-click → Block request URL) to see how the page behaves when a script, font or API fails.
• Copy as fetch or cURL (right-click a request) to replay it in the Console or a terminal.
• Export HAR to share a full recording with a teammate; HAR files can contain cookies and tokens, so check before sending.
• The Initiator column shows which file and line started each request, which is how you find the code behind an unexpected call.

Performance Panel: Core Web Vitals and Runtime Profiling

When you open the Performance panel, it shows live metrics: your local Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) and Interaction to Next Paint (INP), updating as you use the page, with the element responsible for LCP and a log of interactions and layout shifts. You can also turn on field data from the Chrome UX Report to compare your machine with real users.

To dig deeper, click Record (Ctrl+E / Cmd+E), use the page, and stop, or Record and reload (Ctrl+Shift+E / Cmd+Shift+E) to profile a page load. The recording shows a timeline of network requests, frames, the main thread’s work as a flame chart (long tasks are marked in red), and an Insights sidebar that points out problems such as render-blocking requests, layout shift causes and slow interactions. Set CPU throttling to 4x or 6x slowdown before recording, because your laptop is much faster than most of your visitors’ phones. For fixes, see how to speed up JavaScript.

Memory Panel: Find Memory Leaks

If a page gets slower or uses more memory the longer it stays open, the Memory panel helps find what’s being kept alive:

• Heap snapshot: take one, use the feature, take another and compare them to see which objects keep growing. Search for “Detached” to find DOM elements removed from the page but still referenced from JavaScript, a classic leak.
• Allocations on timeline: records allocations over time, so you can see which actions allocate memory that is never freed.
• Allocation sampling: a low-overhead profile of which functions allocate the most memory.

The “Retainers” section of a snapshot shows the chain of references that keeps an object from being garbage-collected, which usually leads straight to a forgotten event listener, timer or cache.

Application Panel: Storage, Cookies and Service Workers

• Storage: view, edit and delete entries in local storage, session storage, IndexedDB and Cache storage.
• Cookies: see every cookie with its domain, expiry and flags (HttpOnly, Secure, SameSite), and edit or delete them.
• Storage → Clear site data: reset everything for the site, the quickest way to test as a new visitor.
• Service workers: update, unregister or bypass a service worker, and simulate offline mode.
• Manifest: check a progressive web app’s name, icons and installability.
• Back/forward cache: test whether the page can be restored instantly when users press Back, and see why not if it fails.

Security, Lighthouse and Recorder

• Security shows whether the page is served securely, its certificate details and any mixed content (HTTP resources on an HTTPS page). It was renamed “Privacy and security” in 2025 and became “Security” again in Chrome 146, with privacy issues such as third-party cookie problems reported in the Console.
• Lighthouse runs an automated audit of performance, accessibility, best practices and SEO, with a score and a list of fixes. Run it in an Incognito window so extensions don’t skew the results. It’s a useful step in any technical SEO checklist.
• Recorder records a user flow (clicks, typing, navigation), replays it, measures its performance, and exports it as a Puppeteer script for automated tests.

Device Mode and Other Useful Tools

• Device Mode (Ctrl+Shift+M / Cmd+Shift+M) simulates phone and tablet screen sizes, touch input and device pixel ratios. It approximates mobile layout, not real mobile performance; test on real devices too.
• Rendering (drawer) can highlight repaints and layout shifts, show a frame-rate meter, and emulate prefers-color-scheme, prefers-reduced-motion and vision deficiencies. It helps to know how the browser rendering engine works.
• Sensors overrides geolocation, device orientation and idle state.
• Coverage shows how much of each CSS and JavaScript file was actually used, a good starting point for removing unused code.
• Screenshots: run “Capture full size screenshot” or “Capture node screenshot” from the Command Menu.

AI Features: AI Assistance and the DevTools MCP Server

Chrome DevTools now includes AI assistance, a Gemini-powered chat panel that can explain an element’s styles, a network request, a source file or a performance trace using the context you select (right-click → Debug with AI). It’s off by default: you enable it in DevTools Settings, it requires signing in with a Google account, and it isn’t available in every region or browser. Treat its suggestions like any other code review comment and verify them.

Going the other way, the Chrome DevTools MCP server (the chrome-devtools-mcp npm package) lets AI coding assistants control a Chrome instance: open pages, read console errors and network requests, and record performance traces, so an agent can check its own changes in a real browser.

Keyboard Shortcuts Cheat Sheet

The full list is in the DevTools keyboard shortcuts reference.

Three Everyday Workflows

“Why does this element look wrong?”

1. Right-click the element → Inspect.
2. Check the Styles pane for crossed-out (overridden) declarations and the Computed tab for the final value.
3. Toggle declarations and edit values until it looks right, then copy the change into your code.

“Why isn’t my data loading?”

1. Open the Console and look for red errors (CORS, 404, JavaScript exceptions).
2. In Network, filter by Fetch/XHR, find the request and check its status, request payload and response.
3. Click the Initiator link to jump to the code that made the request, and set a breakpoint there.

“Why is this page slow?”

1. Open Performance and check the live LCP, CLS and INP values.
2. Turn on CPU throttling and Record and reload, then read the Insights sidebar.
3. Use the Network panel’s waterfall for slow or render-blocking requests, and run Lighthouse for a prioritized list of fixes.

Conclusion

Chrome Developer Tools covers the whole debugging loop: Elements for HTML and CSS, Console for quick checks and logging, Sources for breakpoints and stepping, Network for requests, Performance for Core Web Vitals and profiling, Memory for leaks, Application for storage, and Lighthouse for audits. Learn the Command Menu (Ctrl+Shift+P) and a handful of Console utilities such as $0, $$, copy() and debug(), and you’ll find most problems far faster than by adding console.log calls and reloading. The official Chrome DevTools documentation goes deeper on every panel.

FAQs