Photo by Ferenc Almasi on Unsplash

I used Chrome DevTools almost every single day for about three years before a coworker leaned over during a code review and hit Ctrl+Shift+P on my machine. A little overlay appeared. I had no idea it existed. That was embarrassing.

The thing is, nobody really teaches you DevTools. You pick it up in bits and pieces — a YouTube video here, a Stack Overflow answer there. And so the command palette just sits there, completely invisible, while you're clicking through nested menus looking for the screenshot tool or the coverage tab like some kind of animal. I've seen this a hundred times with developers who are otherwise pretty sharp. The palette is one of those features that should be front and center but somehow isn't.

What I found was that once I started actually using it, I kept discovering commands I didn't even know DevTools had. Some of them changed my debugging workflow completely. So here's the stuff I wish someone had shown me earlier.

Photo by Planet Volumes on Unsplash

Opening the Command Palette (and Why the Shortcut Differs)

The shortcut is Ctrl+Shift+P on Windows and Linux, and Cmd+Shift+P on Mac — but only when DevTools is already open and focused. That last part trips people up constantly. If you hit it while focus is on the page itself, nothing happens. You need to click somewhere inside the DevTools panel first.

Once it's open, you'll see a text input with a > prefix already in there. That > is important. It puts you in command mode. Delete it and you're in file search mode instead, which is a different thing entirely. Honestly, I wish they made that more obvious — the distinction matters a lot and it's easy to miss.

Think of the command palette as a search box for every action DevTools can perform. Instead of hunting through the Settings gear or the three-dot overflow menu, you just type what you want. It's the same idea as the VS Code command palette, which is probably where Chrome's team got the inspiration.

Screenshot Commands You're Probably Not Using

This one genuinely surprised me. Open the palette and type screenshot. You'll see several options come up.

• Capture full size screenshot — grabs the entire page, even parts below the fold
• Capture node screenshot — captures just the currently selected DOM element
• Capture screenshot — standard viewport grab
• Capture area screenshot — lets you drag to select a region

The node screenshot one is ridiculous in how useful it is. Select a card component in the Elements panel, run the command, and you get a pixel-perfect image of just that element. No cropping. No browser extensions. I used to use a separate screenshot tool for this exact thing for years. Years.

And the full-size screenshot beats every browser extension I've tried for long pages because it actually renders the whole document rather than stitching together scroll captures, which always end up slightly misaligned.

Disabling JavaScript Without Installing Anything

Have you ever needed to test how your page looks or behaves with JavaScript turned off? SEO audits, accessibility checks, checking if your server-side rendering actually works. The old way involved going into Chrome settings, finding the content settings, and disabling it there — which also disables it globally, which you'd then forget to turn back on.

In the command palette, just type javascript and you'll find Disable JavaScript. It's scoped to that DevTools session and that tab. When you close DevTools, it resets. When you close the tab, it resets. It's exactly the right level of temporary that you actually want in a debugging context.

This is also handy when you're debugging a page that has aggressive JavaScript redirects or popups that keep interrupting you while you're trying to inspect elements. Just kill JS, poke around in peace, re-enable it.

Finding Dead Code with the Coverage Command

Type coverage in the palette and run Show Coverage. A panel opens at the bottom with a record button. Hit record, interact with your page a bit, stop recording. What you get back is a breakdown of every JS and CSS file loaded, with a percentage of how much of that code actually got executed.

The red bars next to each file are the parts that never ran. For most production sites, these numbers are uncomfortable. I've seen pages where over 60% of the loaded JavaScript was dead weight — stuff from libraries where only one or two functions were actually needed.

This isn't a fix-it-instantly tool. It's more of a diagnostic starting point. But having this surfaced in the command palette means you can pull it up in 30 seconds during any debugging session. You don't need a separate bundle analyzer workflow to at least get a quick read on where bloat is coming from.

Two Insider Tricks Most People Never Find

First one: the > prefix I mentioned earlier can be swapped for other prefixes to change what you're searching. Try typing just ! to search for files, or delete the > entirely to go into the file fuzzy-finder. But the one that's actually useful and almost nobody knows about is the : prefix. Type a colon followed by a number and it jumps to that line in whatever file you have open in the Sources panel. So :247 jumps to line 247. Incredibly handy when a stack trace tells you exactly which line to look at.

Second one: you can use the command palette to change DevTools theme on the fly. Type theme and you'll find the option to switch between light and dark. Useful? Mildly. But here's why it's worth knowing — some DevTools color schemes make it nearly impossible to read certain syntax highlighting. I've been in situations debugging at a client's machine where their screen brightness and office lighting made the default theme nearly unreadable. Knowing you can flip it in three keystrokes is one of those tiny things that saves you from squinting for an hour.

That's Really It

None of this is exotic. The command palette has been in Chrome DevTools since around 2016. But most people learn DevTools through osmosis rather than actually reading the docs, so features like this just stay hidden until someone shows you.

Start with the screenshot commands if nothing else. Seriously. The amount of time I wasted on workarounds for that specific thing is something I'd rather not calculate. And once you get comfortable hitting Ctrl+Shift+P reflexively, you'll start discovering your own commands in there — there are well over a hundred of them. Some you'll never use. But a few will become muscle memory fast.

The best productivity tools are usually the ones already on your machine. You just have to find them first.