Browser DevTools Features Most Developers Never Open

Watch most developers debug a page and you will see the same three moves: open the Elements panel, tweak a CSS value, check the Console for red text. Those panels are useful, but they are maybe a fifth of what the browser gives you. The rest sits behind the double arrow at the end of the tab bar or inside the command menu, and it solves problems people spend hours guessing at.

I spent several years doing cross-browser QA, which mostly means finding out why something works on your machine and not on anyone else's. These are the DevTools features I reach for that rarely come up in tutorials. Examples use Chrome's names, but Firefox and Safari have close equivalents for nearly all of them.

The command menu, which unlocks everything else

Press Ctrl+Shift+P (Cmd+Shift+P on a Mac) with DevTools open. This is the command menu, and it is the fastest way to find features you did not know existed. Type "screenshot" and you can capture a full-page screenshot, including content below the fold. Type "coverage", "rendering" or "sensors" and the matching hidden panel opens.

If you learn only one shortcut from this article, make it this one. Most of what follows is easiest to reach from here.

Network throttling and the request blocking tab

Your office connection and your new laptop hide almost every loading problem. The Network panel's throttling dropdown simulates a slow 4G or 3G connection, and the Performance panel can throttle the CPU by four or six times. Turning both on at once gives you a rough idea of what a user on a three-year-old budget phone experiences.

Request blocking is the quieter companion. Right-click any request and choose to block its URL or its whole domain, then reload. It is the quickest way to answer questions like "what happens if the analytics script fails?" or "does the page still work without the font CDN?" In my experience the answer is surprisingly often "the page breaks completely", and it is better to find that out on purpose.

Coverage: how much of your code is unused

Open the Coverage panel, click reload, and DevTools lists every script and stylesheet with a bar showing how many bytes actually ran during the page load. It is common to see a 300 KB bundle where 70 percent was never executed on that page.

That does not mean you can delete it all, since some code runs only on interaction. It does tell you what to split out and load later. Coverage is also a good companion to the audit described in what modern CSS can do now that used to need JavaScript, because it shows whether the scripts you suspect are dead weight are even running.

Local overrides: edit production without deploying

Local overrides let you save changes to network responses on your own disk and have DevTools serve those edited versions on every reload. You can change a production CSS file, a JavaScript bundle, or even response headers, and see the effect on the real site with real data.

This is how I test a fix for a bug that only appears in production. Edit the minified file in place, reload, confirm it works, then make the same change properly in the source. It is also handy for checking how a page behaves with a different caching header without waiting for a server change.

Layout tools for grid, flex and container queries

In the Elements panel, elements that use grid or flexbox show a small badge. Click it and DevTools draws an overlay with line numbers, gaps and area names right on the page. For grid layouts in particular, this replaces a lot of guessing about which track an item landed in.

The Layout pane lists every grid and flex container on the page so you can toggle overlays for several at once. Container query containers get a badge too, and selecting one highlights the children whose styles depend on it.

Rendering panel: see what the browser is repainting

Open Rendering from the command menu and turn on "Paint flashing". Every area the browser repaints flashes green. Scroll or interact, and you will see whether a small hover effect is causing the whole page to repaint. "Layout shift regions" highlights elements that move unexpectedly, which is the visual side of the Cumulative Layout Shift metric.

The same panel lets you emulate prefers-reduced-motion, dark mode, print styles and vision deficiencies such as blurred vision or different kinds of colour blindness. That last option is one of the cheapest accessibility checks available, and it pairs well with the manual testing in keyboard navigation is the accessibility test most sites fail.

Why "just use console.log" is weaker advice than it sounds

Plenty of experienced developers say they never use breakpoints and that console.log is all you need. I understand the appeal, but I think it is a habit worth breaking for anything beyond a quick check.

Logging requires you to guess in advance which values matter, edit code, and reload. Breakpoints let you pause and inspect everything in scope, step forwards, and change values live. Conditional breakpoints pause only when, say, items.length === 0. Logpoints print a message without editing the source at all, so you never ship a stray log by accident. DOM breakpoints pause when an element is modified, which is the fastest way to find which script is changing something you did not expect.

Use logs when they are faster. But if you have reloaded the same page six times adding more log lines, a breakpoint would have answered the question on the first try.

Memory and performance, briefly

The Performance panel records everything the main thread does over a few seconds, broken into scripting, rendering and painting. It is the tool for "why does this feel janky?" The Memory panel takes heap snapshots, and comparing two snapshots taken before and after an action shows what was created and never freed.

Both deserve a full article of their own. If you want a worked example, our guide on how developer tools help debug online game performance walks through a real stutter from recording to fix.

None of these features are secret. They are just a click or two further away than the Console, and that is enough to keep them unused. Spend half an hour opening each one on a project you know well. You will almost certainly find something you have been doing the slow way. For more, browse our Dev Tools section.