I was recently adding Google Tag Manager tracking on a project by setting up an event that was supposed to fire when a user clicked a button. Standard stuff. The only problem? That button triggered a page redirect.

Click it, gone 😶‍🌫️

The event would technically fire, but the page would navigate away so fast that I had no way to catch it in the Network tab and confirm the tag was actually working.

My first instinct was to slow things down manually, like add a delay somewhere, maybe intercept the click in the code temporarily.

But that felt wrong. It smelled of scope creep.

Then I stumbled onto something in Chrome DevTools I hadn’t used before: Event Listener Breakpoints under the Sources panel.

You expand a category called “Load,” check beforeunload, and the browser freezes execution right before the page navigates.

The redirect never happens. I could open the Network tab, find my GTM event request sitting right there, confirm it fired correctly, uncheck the breakpoint, and move on.

That about sums Chrome DevTools for me. It’s not a single dramatic discovery, but an ongoing pattern.

Every time I go deeper, trying to solve a real problem, I find something that surprises me.

A tool I didn’t know existed. A workflow that makes something I was doing the hard way suddenly simple.

None of it requires a paid subscription, a plugin, or a separate tool. It’s all sitting there in your browser right now.

Why Don’t People Use Chrome DevTools?

The problem with Chrome DevTools is the interface.

DevTools has many tabs, panels, and settings. Unless someone shows you what’s there or you stumble into it while troubleshooting, most of it stays invisible.

I’ve hit that wall plenty of times across different kinds of work: layout bugs, GTM implementations, site speed investigations, and setting localStorage variables for testing.

Every time, DevTools had something useful. I just had to find it.

That’s what this post is for. Whether you’re a developer tracking down a bug, someone managing site performance and SEO, or a marketer trying to understand what’s happening under the hood, there’s a lot here for you.

We’re covering the core panels and what most people miss about them, the hidden features worth knowing, and the AI tools now baked into DevTools.

Stick to the end for a “here’s what most people do vs. the better way” section and practical workflows you can try today!

It’s a worthy read, so let’s get into it 👇

Opening DevTools, And the One Shortcut Worth Memorizing First

Three ways to open Chrome DevTools:

• F12 (Windows/Linux)
• Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac)
• Right-click anywhere on a page → Inspect

If you’re new to it, the right-click method is the most intuitive. The keyboard shortcut becomes automatic pretty quickly.

Now, the one shortcut worth memorizing before anything else: Ctrl+Shift+P (Windows/Linux) or Cmd+Shift+P (Mac).

This opens the Command Menu, which is a search bar that surfaces every DevTools feature, panel, and action in one place.

Think of it the way VS Code users think of the Command Palette. Instead of hunting through menus, you type: “Show Animations,” “Capture screenshot,” “Disable cache”. It’s all in there.

We’ll reference it throughout this post, and by the end, it’ll probably be the first thing you reach for.

The Core Panels, And What Most People Miss About Them

Most people who use DevTools have opened the Elements tab, some have ventured into the Console, and an even smaller number have attempted Network.

They’ve used them in limited ways and moved on.

Here’s what’s actually available when you go one level deeper in each.

Elements: Not Just for Checking Class Names

What most people do: Right-click an element → Inspect → confirm a class name or check a color → close DevTools.

What’s actually available:

Live Editing: HTML and CSS Together

In the Elements panel, you can click any element in the DOM tree and edit it directly.

Press F2 on a selected element to edit its HTML, not just the CSS, but the actual markup.

You can change tag names, add attributes, restructure children, and insert new elements entirely.

None of this touches your source files (a page refresh resets everything), but for rapid visual prototyping before you write the real code? It’s faster than switching back and forth to your editor 💁‍♀️

On the CSS side, click any property value in the Styles pane and change it live.

Toggle properties on and off with the checkbox next to them. See the result on the page instantly.

This works equally well for developers testing a fix and for designers checking whether a change looks right before writing a formal feedback note. (And, dear designers, please go the extra technical mile, it’s deeply appreciated 🙏)

Styles vs. Computed: Why Your CSS Isn’t Applying

This is one of the most misunderstood parts of the Elements panel, and clearing it up saves a lot of head-scratching.

The Styles sub-tab shows every CSS rule that targets the selected element, including ones being overridden.

Overridden rules appear with a strikethrough. This tells you that rules are competing, but it doesn’t always make clear which one is winning.

The Computed sub-tab shows the final answer. That’s the actual resolved value after all specificity, inheritance, and cascade logic have played out.

If a margin isn’t behaving the way you expect, Computed will show you exactly what the browser is applying and, if you expand the property, which rule it came from.

This is useful well beyond developer debugging.

If you’re a marketer or SEO specialist checking whether a page matches brand guidelines (correct font sizes, the right color values, expected line heights), Computed gives you those exact values without guessing through a stylesheet.

Related: Common CSS Selectors To Know And How To Use Them

Flexbox and Grid Visual Overlays

When you select an element that uses display: flex or display: grid, a small badge appears next to the property in the Styles pane.

Click it, and Chrome draws a live overlay on the page with grid lines, column and row divisions, gaps, and alignment guides.

You can see exactly how items are being distributed without inspecting each child individually.

Flexbox and Grid can behave unexpectedly when items are different sizes or when alignment properties interact with each other.

The overlay makes what’s happening immediately visible rather than something you have to reason through.

DOM Breakpoints: Finding the Script Behind a Mystery Change

Here’s a scenario: something on your page is changing, and you don’t know which script is responsible.

A class is toggling unexpectedly. An element is disappearing at the wrong time. Or, an attribute is getting rewritten.

You could search through the JavaScript manually, or you could set a DOM breakpoint and let the browser find it for you 😌

Right-click any element in the Elements panel → hover Break on → pick one:

• Subtree modifications: fires when any child element is added, removed, or changed
• Attribute modifications: fires when any attribute on the element changes (a class toggling, a data- attribute updating, etc.)
• Node removal: fires when the element itself is removed from the DOM

The next time that change happens, execution pauses, and DevTools drops you straight into the Sources panel at the exact line of JavaScript responsible. No hunting required.

I actually used a breakpoint with a Node removal break today at work. Fullstory was showing some crazy disappearing act going on with a button, and I wasn’t about to traverse 5 different sites to identify what in the world was happening. The breakpoint pointed me at the exact file I needed to look at, no time wasted.

Tip 💡
The Color Picker in the Styles pane is more capable than it looks. Click any color value and a picker appears. You can switch between HEX, RGB, and HSL, use the eyedropper to sample any color from the page, and see the contrast ratio between that color and its background for accessibility checks. No separate tool needed.

Console: There’s a Lot More Than Error Messages Here

What most people do: Open the Console to read error messages, scroll through red text, and Google the error.

What’s actually available:

console.table() — Actually Readable Data

If you’ve ever logged an array of objects and tried to make sense of the collapsed [Array(50)] output, you know how quickly that gets frustrating.

console.table() renders that same data as a proper, sortable table with each key becoming a column header and each item a row.

const products = [
  { name: "Sneaker A", price: 89, inStock: true },
  { name: "Sneaker B", price: 120, inStock: false },
  { name: "Sneaker C", price: 65, inStock: true }
];
console.table(products);

Instead of clicking through a nested object, you get a table you can actually read and sort by column.

It’s seriously useful for anyone debugging API responses or working with lists of data.

console.time() and console.timeEnd() — Quick Performance Checks

Want to know how long something takes without setting up a profiler?

console.time("fetchProducts");
// your fetch call or heavy operation here
console.timeEnd("fetchProducts");
// logs: fetchProducts: 143.2ms

Wrap any code with a labeled timer, and the Console outputs the elapsed time.

There’s zero setup and no extra tooling.

console.group() — Organized Logs

When you’re logging several related things at once, and the Console is getting cluttered, console.group() lets you nest logs under a collapsible label:

console.group("User Session");
console.log("User ID:", userId);
console.log("Token:", authToken);
console.log("Expires:", expiryDate);
console.groupEnd();

All three logs appear under a “User Session” header, which you can collapse and expand.

This keeps things readable when a lot is going on.

The $ Shortcuts: Less Typing, More Done

These Console-only shortcuts are worth knowing. Most developers haven’t seen them:

• $0 — a live reference to whatever element is currently selected in the Elements panel. Click an item in the Elements tab, come back to the Console, type $0 and that’s your element. Run $0.getBoundingClientRect(), $0.textContent, or getEventListeners($0) without writing a querySelector.
• $1, $2 — the previously selected elements, in reverse order of selection.
• $_ — the result of the last evaluated expression. If you ran something and want to reuse the result without running it again, $_ gives it back.
• $$('selector') — equivalent to document.querySelectorAll(). So $$('img').map(img => img.src) returns every image URL on the page in one line.
• copy(anything) — copies any value to your clipboard directly from the Console.

I came across the last one when trying to copy an object via right click, only to get "[object Object]". Talk about annoying 🙄

If you try copy(someObject) and all you still get the string "[object Object]", the object wasn’t serialized before copying.

Force it into something readable first:

copy(JSON.stringify(someObject, null, 2))

That gives you the full object as a formatted JSON string you can paste anywhere.

Note: These $ shortcuts are Console-only. They’re not available in your actual JavaScript files. Sorry.

Sources: The Panel Most People Avoid (And Shouldn’t)

What most people do: Scatter console.log through the code, check output, delete logs, and add some more. They repeat until fixed and leave two in there by accident.

What’s actually available:

The Sources panel that’s built into Chrome is the full JavaScript debugger.

Most people avoid it because the interface looks dense, but the core workflow is straightforward.

In fact, it replaces most of the console.log cycle once you’re comfortable with it.

Standard Breakpoints: Pausing Execution at a Specific Line

In Sources, open any JavaScript file from the file tree on the left. Find the line you want to investigate and click the line number. A blue marker appears.

Reload the page. When execution reaches that line, everything pauses.

The entire runtime state is frozen right there. Every variable currently in scope shows up in the Scope pane on the right side of the panel. The full call stack (which functions called which, in what order) is visible below it.

You can also run expressions in the Console at this exact moment to interrogate or reassign any value.

A concrete example of when to use it: Say you have a function that builds a shopping cart total, and somewhere it’s returning the wrong number.

You add a breakpoint on the line where the total is calculated.

When the page pauses there, you can see every variable involved, from item prices and quantities to discount values, in their actual state at that moment.

You’re not guessing from log output. You’re looking at the live runtime.

Conditional Breakpoints: Breaking Only When It Matters

Standard breakpoints get noisy fast. Think about it: if the line you care about runs inside a loop that iterates 200 times, you’ll be clicking “Resume” 199 times to get to the case you actually want 🙂‍↕️

What most people do: Write if (condition) { console.log(...) } in the source code, test, then manually remove it.

The better way: Right-click the line number → Add conditional breakpoint → type your condition.

The breakpoint only fires when that condition evaluates to true. Everything else runs normally.

Now, you might be asking: Where do you put the breakpoint? On the function definition, or on the specific line inside the function you want to test?

Put the breakpoint on the specific line inside the function where the value you’re investigating is accessible.

For example, if you’re checking whether userId is undefined at the point where a fetch call is made, put the breakpoint on the fetch line, not on the function declaration above it.

That’s the line where userId is in scope and where you’d catch the problem!

// Only pause when a specific user ID is involved
userId === "abc-123"

// Only pause when an API response comes back with an error
response.status >= 400

// Only pause on a specific loop iteration
i === 49

There are no source code changes. There’s no cleanup. The conditional breakpoint lives entirely inside DevTools and disappears when you remove it.

Logpoints: console.log Without Touching Your Code

Right-click a line number → Add logpoint → type a message.

The browser logs that message to the Console every time execution reaches that line without pausing and without adding a single line to your codebase.

"Cart total: " + cartTotal + " | User: " + userId

A pink dot appears on the line to show the logpoint is active. Remove it the same way you’d remove a breakpoint.

Logpoints survive page reloads for the duration of your DevTools session, which makes them especially useful when you want to add temporary logging to a production build without touching the actual code 🔥

Event Listener Breakpoints: The GTM Tracking Example

This is the feature I mentioned in the intro. Under the Sources panel, look for Event Listener Breakpoints in the right sidebar, and you’ll find a collapsible list of event categories.

Expand any category to find the individual events you can intercept.

Checking beforeunload under the Load category pauses the browser the moment a page starts to navigate away.

That’s what caught my GTM event on that redirecting button! The browser froze mid-redirect. I checked the window data layer to confirm the tag request was there before unchecking the box and allowing the redirect to continue.

Other practical uses from the same sidebar:

• Check click under Mouse to find what’s handling a click event you can’t track down in the source
• Check submit under Form to catch any form submission before it fires
• Or check XHR → readystatechange to intercept AJAX requests as they happen

These are the kinds of things you’d otherwise spend an hour hunting through source code to find.

Stepping Through Code: What It Actually Means

Once you’re paused at a breakpoint, you can navigate through execution one step at a time using three controls:

• F10 — Step Over: Run the current line and move to the next one in the same function. Use this when you want to watch how the current function progresses line by line, without going inside any function calls it makes.
• F11 — Step Into: Enter the function being called on the current line. Use this when the function call on the current line is where you think the bug lives and want to follow execution inside it.
• Shift+F11 — Step Out: Finish the current function and return to where it was called from. Use this when you’ve stepped into a function and realized it’s not what you were looking for, so you want to step back out.

A real example of when to use stepping: You’re paused on a line that calls calculateDiscount(cart). You’re not sure if the bug is in calculateDiscount or in the code that handles the result afterward.

Press F11 to step into calculateDiscount—now you’re inside it. Watch the variables in the Scope pane update as you step through each line with F10.

If everything looks right inside the function, press Shift+F11 to step back out and check what happens to the return value after.

The Scope pane shows you live variable values at each step. The Console lets you test expressions mid-execution. Together, they give you a complete picture of what’s actually happening, not what you think is happening based on log output.

Tip 👀
When debugging a React or Vue app, the call stack fills up fast with framework internal code. You can tell DevTools to ignore those files entirely by right-clicking any file name in the call stack that belongs to a library (like react.development.js or vue.runtime.esm.js) and select Add script to ignore list. DevTools will skip over those files when stepping, keeping your focus on your own code.

Network: Traffic Inspector, API Debugger, and More

What most people do: Open Network, reload, look for red requests, check the status code.

What’s actually available:

Filtering Requests

The filter bar at the top of the Network panel accepts both type buttons (XHR, Fetch, JS, CSS, Img) and text input.

• Type api/users and only requests matching that URL fragment show.
• Use a negative filter like -static to hide anything with “static” in the URL.
• You can also filter by response header values using has-response-header:content-type syntax.

For marketers and SEO folks: filtering by Doc and XHR gives you a clean view of the page document request and any dynamic data calls. This is useful for understanding what a page is loading without going through every font file and image.

Deep Request Inspection

Click any request in the Network panel to open its detail view. You’ll see four tabs worth knowing:

• Headers: request and response headers, status code, content type
• Payload: what was sent in the request body (for POST/PUT requests, it’s useful for confirming form submissions or that API calls are sending the right data)
• Response: the actual data that came back
• Timing: a breakdown of how long each phase of the request took

That Timing tab is underused. If a request takes 2 seconds, Timing tells you whether that’s time spent on DNS lookup, waiting for the server to respond, or downloading the response body.

Those are three completely different problems, and Timing tells you which one you’re actually dealing with.

Replaying and Copying Requests

Right-click any request in the Network panel:

• Replay XHR: re-fires the request without reloading the page, useful for testing the same call multiple times
• Copy → Copy as fetch: gives you the exact fetch() syntax to reproduce that request in the Console or your code
• Copy → Copy as cURL: same thing as a cURL command, useful for terminal testing or sharing with a backend developer

The “Copy as fetch” approach is particularly useful since it allows you to grab an API call the UI made, paste it into the Console, modify the payload or headers, run it, and see the response.

All without touching the UI at all!

Network Throttling: Testing What Real Users Experience

The dropdown in the Network panel toolbar that says “No throttling” is easy to overlook. Click it, and you’ll find options like:

• Slow 3G: roughly what users on older mobile devices with poor signal experience
• Fast 3G: better mobile, but still significantly slower than a home connection
• Offline: simulates no connection, useful for testing error states and offline behavior

Switch to Slow 3G and reload your page. If your loading state is a blank screen for 4 seconds, your users on slow connections experience that blank screen for 4 seconds.

This is how you find out before they do.

For SEO and marketing folks: Google’s Core Web Vitals measurements, especially LCP (Largest Contentful Paint), are directly affected by how fast a page loads under real network conditions. Throttling is a fast way to understand what your actual performance looks like before running a formal audit.

Local Overrides: Intercepting Requests Without a Server

This is one of the most powerful features in DevTools and one of the most underused.

Let’s say you need to test how your UI handles a specific API response you can’t control. Assume the backend doesn’t support the edge case yet, you’re blocked by a CORS error, or you want to test an empty state without touching the database.

What most people do: Set up a separate mock server, use a library like MSW, modify environment variables, or ask the backend team to temporarily change something.

The better way: Local Overrides let you intercept any network request and serve your own response from a local file, all in the browser without a server involved.

To mock an API response:

1. In the Network tab, find the request you want to override
2. Right-click → Override content
3. First time only: DevTools will ask you to pick a local folder to store the override files. Pick one and click Allow in the permission dialog that appears
4. The response JSON opens directly in the Sources panel editor
5. Edit it to whatever you need, be it an empty array, an error object, or edge case data
6. Ctrl+S to save
7. Refresh the page

Your page now renders against your local file instead of the real API response, and this persists across page reloads until you turn it off.

To fix a CORS error without touching the server:

1. Right-click the failing request → Override headers
2. Click Add header
3. Name: Access-Control-Allow-Origin / Value: *
4. Save and refresh

The CORS error is gone without any server changes or proxy configuration. If you’re still blocked, you might be looking at a pre-flight (OPTIONS) request instead of a simple one and, so, ran into a limitation.

Note 🟣
Local Overrides are entirely local to your browser session. They don’t affect other users, other browsers, or your production environment. DevTools marks overridden requests with a purple dot in the Network panel so you can see at a glance what’s being intercepted. When you’re done, turn them off under Sources → Overrides.

Hidden Features Worth Knowing About

Moving on, let’s take a look at some hidden features. Not “hidden” because they’re buried in obscure settings, but because they’re features that don’t get surfaced loudly.

Most people never find these features unless someone points them out.

In case you’re wondering, I’m gonna be doing the pointing 😇

Design Mode: Edit Any Text on Any Page

Run this in the Console:

document.designMode = 'on';

Your browser window becomes editable, like a text document.

Click any text on the page and type. This is useful for:

• prototyping copy changes
• checking how different text lengths break a layout
• taking realistic-looking screenshots for a presentation without photoshopping anything

Turn it off the same way:

document.designMode = 'off';

For marketers and content folks: this is also a fast way to check what a headline or CTA change would look like on a live page before routing a formal request to a developer.

CSS Overview: A Full Audit of Your Stylesheet

Open via Command Menu → type “CSS Overview” → click Capture overview.

What you get is a full visual report of your page’s CSS:

• Colors: every color value in use, grouped visually. Near-duplicates that might be inconsistencies show up here.
• Fonts: every font family, weight, and size in use across the page
• Media queries: a count and list of all responsive breakpoints being used
• Unused declarations: CSS that’s been defined but isn’t applied to any currently visible element

For developers, this is a fast audit of stylesheet bloat.

For designers or QA reviewers, it’s a quick check that the implementation matches the design system with correct fonts, correct palette, and nothing unexpected.

Animations Panel: Slow Motion for CSS

Open via Command Menu → “Show Animations.”

Any CSS animation or transition on the page appears as a timeline.

You can scrub through frame by frame, slow everything down to 10% speed, pause at any point, and even adjust timing values directly in the panel.

Tip: If you’ve ever refreshed a page over and over trying to catch a detail in an animation that runs too fast, this is how you stop doing that.

The Coverage Panel: Find Dead CSS and JavaScript

Open via Command Menu → “Show Coverage” → click the record button → interact with your page normally → stop recording.

The panel shows every JavaScript and CSS file loaded by the page, with a horizontal bar showing how much of each was actually executed or applied during your session.

Red means it didn’t run. Green means it did.

Tip: If a CSS file shows 70% red, that’s a lot of styles being downloaded by every visitor that never get used on this page. That has direct performance implications, especially for Core Web Vitals.

The Coverage panel tells you which files to investigate first and gives you a data-backed reason to clean them up.

Performance Monitor: Real-Time Metrics

This one is different from the full Performance panel (which records a session for later analysis).

The Performance Monitor is a live dashboard. Open it via the three-dot menu in DevTools → More tools → Performance Monitor.

You’ll see real-time graphs of CPU usage, JavaScript heap size, DOM node count, and active event listener count.

The most practical use is to catch memory leaks.

If your JS heap keeps climbing as you interact with the page and never drops back down, something isn’t being cleaned up properly.

You’ll see it happening live rather than waiting until a user reports that the page gets sluggish after 10 minutes.

Lighthouse: The Free Performance and SEO Audit

The Lighthouse panel (find it in the top tabs or via Command Menu → “Generate Lighthouse report”) runs a scored audit across four categories: Performance, Accessibility, Best Practices, and SEO.

Click Analyze page load, and you get a prioritized report with actual scores, specific issues flagged, and the estimated impact of each fix.

For SEO specialists: the SEO section catches missing meta descriptions, uncrawlable links, missing alt attributes on images, and tap target sizing issues on mobile.

Basically, most of the technical on-page fundamentals that affect crawlability and ranking signals.

It’s not a full SEO platform, but for technical health and Core Web Vitals compliance, it covers what the browser can measure directly.

For developers: the Performance section identifies render-blocking resources, oversized images, unused JavaScript, and anything slowing down Time to Interactive.

The report also pulls in field data from the Chrome UX Report when available, giving you a comparison between what DevTools measures on your machine and what real users are experiencing in the wild.

Explore: This Is A Super Easy Optimization Workflow For SEO & Accessibility

Five “Here’s What Most People Do, And the Better Way” Moments

These are five patterns where DevTools has a better approach that most people haven’t found yet.

1. Debugging: Break Instead of Logging

What most people do: Add console.log() everywhere, reload, read output, add more logs, delete old ones, eventually find the issue, leave two console.log statements in there that make it to production.

The better way: Use a logpoint or breakpoint in the Sources panel.

For a quick value check: right-click a line number → Add logpoint → type what you want to see.

It logs to the Console on every execution without touching your code, so there’s nothing to clean up.

For a real debugging session: add a breakpoint, reload, and when execution pauses, you’ll find every variable that’s in scope in the Scope pane.

You can interrogate the live state of your application, reassign variables in the Console to test different conditions, and step through execution line by line until you find exactly where things go wrong.

2. API Work: Mock Instead of Waiting

What most people do: Wait for the backend to be ready. Set up a separate mock server. Hardcode temporary data in the frontend and remember to remove it later (or don’t 😬).

The better way: Use Local Overrides in the Network panel to intercept the request and serve whatever JSON you need.

Takes about two minutes to configure the first time. You can test empty states, error conditions, and edge cases against a real UI without leaving the browser or involving anyone else.

3. Performance Testing: Throttle First, Then Optimize

What most people do: Test site performance on a developer laptop with a fast internet connection and treat those results as representative of the user experience.

The better way: Before auditing anything, simulate real-world conditions.

Set network throttling to Slow 3G in the Network panel dropdown, and set CPU throttling to 4x slowdown in the Performance panel.

Tip 👇
To find CPU throttling, open the Performance panel → click the gear icon (⚙) in the top right of the panel → you’ll see a “CPU throttling” dropdown right there.

Together, these approximate what a real user on a mid-range mobile device with mobile data actually experiences.

The problems that show up under these conditions are the ones worth fixing.

Problems that only appear on your fast machine are a much lower priority.

4. Event Debugging: Break on Events Instead of Hunting Code

What most people do: Search through JavaScript files manually, looking for event listeners, or add temporary console.log statements inside handlers to confirm they’re firing.

The better way: Use Event Listener Breakpoints in the Sources panel. Expand the right sidebar, find the event category, check the specific event (click, submit, beforeunload, etc.), and the browser pauses the moment that event fires on any element on the page.

From there, the call stack shows exactly where the handler is defined and what called it.

This is especially useful for dynamically attached event listeners, third-party scripts, and GTM tracking implementations. Essentially, anywhere the handler is that you cannot easily search for in the source.

5. Design QA: Diagnose Before Filing a Bug Report

What most people do: Notice a visual issue, take a screenshot, write a vague bug report (often without a link 😒), wait for a developer to look at it.

The better way: Open the Elements panel, select the element, and tweak the CSS in the Styles pane until you find what the correct value should be.

Then include that specific fix in the report:

• “The padding-top on .hero-cta should be 24px not 16px” takes a developer 30 seconds to fix
• “The button looks off on mobile” does not

You can also check color contrast directly in the Color Picker—click any color swatch in the Styles pane and look for the contrast ratio.

Below 4.5:1 means it’s failing WCAG AA accessibility standards. You can flag this without using a separate accessibility tool (or you can use THT’s free SEO & Accessibility Helper Chrome extension if memory isn’t doing you favors).

The AI Assistance Panel: Gemini Built Into DevTools

This is a newer addition that’s absolutely worth knowing about.

Google integrated Gemini directly into Chrome DevTools, not as a sidebar chatbot, but as a contextual assistant that has access to what you’re actually inspecting: the DOM, styles, network requests, source code, and performance profile.

How to Open It

Click the AI assistance button in the top-right corner of the DevTools toolbar (it looks like a stars/sparkle icon).

You can also right-click any element, network request, or stack frame and select Ask AI, or in newer versions of Chrome, Debug with AI, to open the panel with that item’s context already loaded.

Command Menu → type “AI” → Show AI assistance also works.

You’ll need to be signed into Chrome with a Google account and have AI assistance enabled. It does not work in Incognito.

Tip: If you don’t see the button, go to DevTools Settings → Preferences, or check the Experiments tab, and look for the AI assistance toggle.

Five Ways to Start Using It

1. Understand a confusing console error

Hover over any error in the Console, and an AI icon appears next to it. Click it.

The panel reads the error message, the stack trace, and the related source code, then explains what’s actually happening and suggests fixes.

This is particularly useful for framework-specific errors, like React key warnings and Vue lifecycle issues, where the error message alone doesn’t tell you much.

2. Debug a styling problem

In the Elements panel, select the element with unexpected behavior, open AI assistance, and describe what you’re seeing: “Why is the margin on this element not applying?”

The AI can traverse the DOM, read the computed styles, check for conflicting rules, and explain the cause with specific CSS properties and values to fix it.

I’ve been using this feature a lot. I like it 🙂

3. Understand an unfamiliar or minified script

If you’re looking at a third-party JavaScript file or a minified production bundle and you can’t tell what it does, ask the AI to describe it.

It can explain the code’s purpose and behavior without you having to reverse-engineer it manually.

Super useful when investigating an unknown script from an analytics platform or ad network!

4. Investigate a slow network request

In the Network panel, right-click any request that looks slow → Ask AI.

Describe the symptom, and the AI will analyze the request headers, response time breakdown, and payload size to suggest where the bottleneck might be and what to look at next.

I’m sorry, but if you’re not using this, what are you doing? It’s free!

5. Get suggestions from a performance profile

In the Performance panel, right-click any function in the flame chart → Ask AI.

The panel reads the recording and tells you which functions are taking the most time, why, and what to consider fixing without you having to interpret the flame chart notation yourself.

Note 📍
AI assistance is still experimental, and the responses aren’t always perfect. Treat it as a knowledgeable starting point. It’s usually enough to point you in the right direction, and it’s faster than a cold Google search for most DevTools-specific questions. But, do keep in mind, that responses and interactions may be sent to Google for training.

Practical Workflows to Try Today

Workflow 1: QA a GTM Tag on a Redirecting Button

The problem: You set up a GTM event on a button that navigates away on click. By the time DevTools captures anything, the page is already gone.

The workflow:

1. Open DevTools → Sources panel
2. In the right sidebar, expand Event Listener Breakpoints
3. Expand the Load category → check beforeunload
4. Click the button — the browser freezes right before the redirect
5. Switch to the Network tab or check your data layer (i.e., where you anticipate this to show up)
6. Confirm it fired, check the payload if needed
7. Uncheck beforeunload — the redirect continues

No extensions. No GTM preview workarounds for this specific case. This same pattern works for any tag or event you need to catch before a page navigates away.

Workflow 2: Test an Empty State or Error Without a Backend Change

The problem: You want to see how your UI handles an empty response or a specific error, but the real API always returns populated data.

The workflow:

1. Network tab → find the API request
2. Right-click → Override content → pick a local folder if this is your first time
3. In the JSON editor that opens, change the response to what you want to test:

// Empty state
[]

// Error condition
{ "error": "Not found", "status": 404 }

// Single result (testing minimal data)
[{ "id": 1, "name": "Only One Result" }]

4. Ctrl+S → refresh → your UI renders against your local mock data

When done: Sources → Overrides → disable or delete the override file.

Workflow 3: Audit a Page You Don’t Have Access To

The problem: A client or collaborator asks why their page is slow. You don’t have access to the codebase or hosting environment.

The workflow:

1. Open the page in Chrome → open DevTools
2. Network tab → set throttling to Slow 3G → hard refresh (Ctrl+Shift+R / Cmd+Shift+R)
3. Watch what loads: requests taking 3+ seconds? Large unoptimized images? Third-party scripts loading synchronously?
4. Command Menu → Show Coverage → record a session → interact with the page → stop. Which files are mostly red?
5. Command Menu → Generate Lighthouse report → Analyze. Read the scored breakdown with specific, prioritized recommendations
6. For any slow request that needs more context: right-click → Ask AI

A thorough performance and technical SEO audit on any public page, in about 10 minutes, no codebase access required.

It’s a Wrap

The thing I keep finding with Chrome DevTools is that it doesn’t get harder as you go deeper. It simply gets more useful.

Every feature in this post exists because someone had a real problem to solve.

Most of them I only found because I had that same problem.

Here’s where to start if you want to actually use this stuff, not just read about it:

• Try a logpoint next time you’d reach for console.log. Right-click a line number in Sources → Add logpoint. Same result, nothing to clean up.
• Set a DOM breakpoint next time something changes on your page, and you don’t know why. Right-click the element in Elements → Break on → Attribute modifications.
• Use Event Listener Breakpoints next time you need to catch an event before a redirect, or you need to find what’s handling a click you can’t locate in the source.
• Run a Lighthouse audit on something you’re currently building. The SEO and Performance scores will give you something specific to act on.
• Set up Local Overrides next time you’re blocked by a backend dependency or a CORS error. Five minutes to configure, then you’re unblocked.
• Open the AI panel next time you hit a confusing console error. Hover it, click the AI icon, see what it says. Though it’s not always perfect, it’s usually a better starting point than a cold search.

Pick one and use it on your next project. When it saves you time, pick another.

And if you run into something in DevTools that surprises you, the way that beforeunload breakpoint surprised me, drop it in the comments.

‘Till next time ✌️