Chrome DevTools Tricks Most Developers Don't Know About

You've been using DevTools since day one. You open it, check the console, inspect an element, maybe peek at network requests. And then you close it.

But DevTools is not a debugger. It's a full developer environment — and most of its power is sitting in tabs you've never clicked.

The Console Is Not Just for console.log

Everyone uses console.log. Almost nobody uses the rest.

console.table() — stops you from squinting at nested objects:

const users = [
  { id: 1, name: "Riya", role: "admin" },
  { id: 2, name: "Dev", role: "editor" },
  { id: 3, name: "Sam", role: "viewer" },
];

console.table(users);
// Renders a clean sortable table — not a collapsed object tree

console.group() / console.groupEnd() — when you're logging across a complex flow and the output becomes noise:

console.group("Auth flow");
  console.log("Token fetched:", token);
  console.log("User decoded:", user);
  console.warn("Token expires in 5 minutes");
console.groupEnd();

console.time() / console.timeEnd() — a quick profiler without opening the Performance tab:

console.time("fetch-users");
await fetchUsers();
console.timeEnd("fetch-users");
// fetch-users: 243.21ms

$_ in the console — references the last evaluated expression. Type an expression, hit enter, then use $_ to continue working with that result without re-running anything.

$(selector) and $$(selector) — inside the DevTools console, $ is document.querySelector and $$ is document.querySelectorAll. Not jQuery — native, built-in shorthand.

// In console — no import needed
$$('a[href]').map(a => a.href)
// Returns every href on the page in an array

Live Expressions — Stop Polluting Your Console

Every developer has done this: added a console.log(someValue) inside a loop or an event listener to watch a value update in real time. The console floods. You can't read anything. You delete the log. You add it back.

Live Expressions fix this permanently.

1. Open DevTools → Console tab
2. Click the eye icon at the top of the console — "Create live expression"
3. Type any JavaScript expression: document.activeElement, window.scrollY, myStore.state.user

The expression evaluates continuously and updates in-place — no flooding, no console.log, no clutter. Especially useful for watching scroll position, monitoring a Redux/Zustand store value, or tracking document.activeElement during focus management debugging.

The Network Tab: Beyond Watching Requests

Most developers use the Network tab to see if a request fired and what it returned. That's 10% of what it does.

Throttle specific requests, not your whole connection. Right-click any request → "Block request URL" or "Block request domain." The request fails with a network error. Use this to test how your app handles API downtime without mocking anything.

Replay a request with edited headers or body. Right-click any request → "Copy as fetch." Paste it in the console. Now edit the body, change a header, add a token — and re-fire it directly from the console. No Postman needed.

// Pasted from "Copy as fetch", then edited
fetch("https://api.example.com/users", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Authorization": "Bearer your-new-token-here"
  },
  body: JSON.stringify({ name: "Test User" })
})
.then(r => r.json())
.then(console.log);

The Initiator column tells you exactly which line of code triggered each network request. Stop searching for where fetch("/api/orders") is called — the Initiator column links directly to the source.

Preserve log is off by default but critical for debugging page redirects. The network log clears on navigation. Turn it on and the full history survives redirects.

The WS filter is underused: it shows WebSocket frames in real time, including message payloads. If you're working with socket.io or any WebSocket API, this replaces a ton of custom logging.

Elements Panel: The Tricks That Save Real Time

Force element state — stop hovering and clicking just to make a CSS state appear. Right-click any element in the Elements panel → "Force state" → :hover, :focus, :active, :visited, :focus-within. This keeps the state locked while you edit CSS in the Styles pane.

Copy JS path — right-click any element → Copy → "Copy JS path." DevTools writes document.querySelector(...) with the exact selector for that element. Paste it in the console and start scripting against it immediately.

$0 through $4 — DevTools tracks the last 5 elements you clicked in the Elements panel. In the console, $0.classList, $0.getBoundingClientRect(), $0.scrollIntoView() all just work — no selector needed.

// In the console, after clicking an element in Elements panel
$0.getBoundingClientRect()
// {x: 20, y: 340, width: 680, height: 44, top: 340, ...}

$0.style.outline = "2px solid red"
// Instantly highlights the element on the page

Sources Panel: Breakpoints You're Not Using

Everyone knows how to set a regular breakpoint. Almost nobody uses the others.

Conditional breakpoints — right-click the line number → "Add conditional breakpoint." Enter a condition. The breakpoint only pauses when the condition is true.

// Only pause when userId is 42
// Condition: userId === 42

// Or when a request is slow
// Condition: Date.now() - startTime > 500

This eliminates the if (someValue === x) { debugger } pattern that inevitably gets committed.

Logpoints — right-click any line number → "Add logpoint." Type a message with {} to interpolate values. It logs to the console without pausing execution and without touching your source code. It's a console.log that lives in DevTools, not in your codebase. Zero chance of accidentally shipping it.

// Logpoint message (no code change needed):
User loaded: {user.name}, role: {user.role}

XHR/fetch breakpoints — in the Sources panel right sidebar → "XHR/fetch breakpoints" → add a URL substring. DevTools pauses execution the moment any fetch or XHR fires to a URL containing that string.

// Add breakpoint for substring: /api/checkout
// Now anytime fetch('/api/checkout/create') fires, execution pauses
// — regardless of which line triggered it

Event listener breakpoints — Sources panel right sidebar → "Event listener breakpoints." Expand any category (Mouse, Keyboard, DOM Mutation, etc.) and check a box. DevTools pauses on every event of that type across the entire page. Debugging a form that submits when it shouldn't? Check "submit" under Form.

Performance Tab: The One Real Use Case to Know

The Performance tab intimidates most developers. You don't need to understand all of it. You need one workflow.

1. Open DevTools → Performance
2. Click Record
3. Do the slow thing (scroll, click, type)
4. Stop recording

Look at the flame chart. Find the long bars — those are long tasks. Long tasks (>50ms) block the main thread and cause jank. Click one. DevTools shows you exactly which function ran, how long it took, and which line of code it came from.

Lighthouse is built in. DevTools → Lighthouse tab → Generate report. It audits performance, accessibility, SEO, and best practices — and gives you specific, actionable items to fix. Run it before every deploy.

Application Tab: Where You're Leaving Data Behind

Application → Storage shows exactly what's in localStorage, sessionStorage, IndexedDB, and cookies. Double-click any value to edit it in-place. Right-click to delete individual keys. This replaces writing localStorage.getItem('token') in the console every time.

Clear site data — Application → Storage → "Clear site data." One button that wipes localStorage, sessionStorage, IndexedDB, cache storage, and cookies in one shot.

Service Workers — Application → Service Workers. Shows which service worker is active, lets you update it manually, and — crucially — lets you "Bypass for network" during development, so cached responses don't mask changes you just made. If you've ever wondered why your CSS change isn't showing up after a hard refresh, a stale service worker is the most common reason.

The Command Menu: Fastest Way to Do Anything

Press Ctrl+Shift+P (or Cmd+Shift+P on Mac) inside DevTools. This opens the Command Menu — a searchable list of every DevTools action.

• Screenshots — capture the full page, a specific node, or the current viewport as PNG without any browser extension
• Dark mode — toggle DevTools between light and dark
• Disable JavaScript — instantly disables JS to test your site's no-JS fallback
• Show rendering — opens the Rendering panel (paint flashing, layout shift regions, FPS meter)
• Coverage — shows which CSS and JS is actually used vs. loaded, helping you find dead code in production

The Rendering panel deserves special mention. Enable "Layout Shift Regions" and interact with your page. Any element that shifts highlights in blue. This is how you debug Cumulative Layout Shift (CLS) without reading a report.

Common Mistakes

• Hardcoding debugger statements and committing them — use logpoints instead; they live in DevTools, not your code
• Throttling the whole network to test slow connections — block specific requests instead to test error states without slowing everything down
• Ignoring the Initiator column — when you can't find what's making a request, it's the first place to look
• Never using Preserve log — if you're debugging a redirect and the network tab is empty, this is why
• Clearing localStorage manually via the console — Application → Clear site data is one click and catches everything, including caches you didn't know existed

The Takeaway

DevTools is not a viewer — it's a workbench. Logpoints keep debug code out of your commits. Live Expressions replace the console.log flood. XHR breakpoints find mystery API calls. Conditional breakpoints kill the if (x) { debugger } pattern. The Command Menu is faster than clicking through every tab. Most of this is already installed in your browser. You just haven't opened the right panels yet.