I was working on a feature and got a design fix reference from a designer on my team. It was one of those annotated screenshots that usually sparks questions. But this one was different. Instead of a red circle and a vague comment, there was a clean overlay showing exactly what element had the spacing issue, its current values, and what they should be.

I remember staring at it, thinking: What tool did she use to get that?

Turned out it wasn’t a tool at all. It was Chrome DevTools—the same panel I open every day.

She’d just gone in further than most people bother to 🥲

That moment stuck with me because the fix took me seconds. One glance and I already had a mental picture of what needed to change.

There was no back-and-forth. No “can you be more specific?” No guesswork or futile scavenging.

Chrome DevTools has a whole set of features that are genuinely useful for anyone on the visual side of building for the web. I’m talking designers, UI/UX folks, anyone who cares about how things look and feel when they ship.

Most of these features are sitting there unused because the name “DevTools” makes it sound like it’s not for you.

Let me correct that: It is for you.

No deep coding background needed. You can open a browser and use what’s in here.

If you’ve been following along with the Chrome DevTools general deep dive, this goes in an entirely different direction.

In this post, we’re looking at the panels and features that make design review, QA, and in-browser exploration faster and more precise, with or without a developer in the room.

Why “Developer Tools” Is a Misleading Name for What This Actually Is

The name says “developer.” The icon is angle brackets. The default view is full of code. Fair enough, I get it.

But DevTools has grown into something much broader than a JavaScript debugger.

A lot of what’s in there today was built specifically for designers, accessibility reviewers, and anyone doing QA on a live web interface. For people who need to see what’s actually on the page, not just what’s in the source files.

The problem isn’t the tools, but that nobody told you they were there.

Note: Never opened DevTools before? Press F12 (Windows/Linux) or Cmd+Option+I (Mac) on any webpage. That’s it! Everything in this post lives inside that panel.

One more shortcut to know before we go anywhere:

• Ctrl+Shift+P (Windows/Linux)
• Cmd+Shift+P (Mac)

This opens the Command Menu, which is a search bar for finding any DevTools feature by name.

DM says: Think Spotlight, or Figma’s quick actions.

We’ll come back to it often.

The Panels That Actually Matter for Design Work

We’ll start by taking a look at what’s worth knowing about, and why.

Some of these you’ve probably seen. Others, probably not.

The Elements Panel: Inspect, Measure, and Force States on Any Live Page

This is the panel most people have at least glanced at. It shows the page’s HTML structure and the CSS applied to each element.

For anyone on the design or UI side, the interesting thing isn’t really the code but what you can do with it while looking at a live page.

How to Read Exactly What’s on the Page (Font, Size, Spacing)

Press Ctrl+Shift+C (or Cmd+Shift+C on Mac) and your cursor turns into an inspector 🤯

This is the same thing the designer was using when she sent me that reference screenshot. She hadn’t built any special tool; she’d just found this.

Hover over anything on the page, and a tooltip shows up with:

• Font family, size, and weight
• Element dimensions (width × height)
• Margin and padding values
• Color values

That’s your starting point for checking whether what shipped matches what was designed without guessing and with no developer ping required.

You look at the numbers.

Once you click to select an element, the Computed sub-tab (right next to “Styles”) shows the final resolved values the browser is actually applying.

Note: This is not the raw CSS. It’s the result after all the cascading and inheritance have played out.

If a margin looks wrong and you can’t figure out why, Computed has the answer.

How to Inspect Hover and Focus States Without Them Disappearing

Say you want to check a button’s hover state, specifically, the color, the border, or whatever changes when you mouse over it.

The moment you move your mouse to click something in DevTools, the hover state is gone.

That’s always been the annoying part.

DevTools has a fix for this called Force Element State.

Select any element in the Elements panel. In the Styles pane, click the :hov toggle near the top, and a small dropdown appears with checkboxes:

• :hover
• :focus
• :active
• :visited
• :focus-within

Check :hover and the element stays locked in that state even while you click around in DevTools.

You can inspect hover colors, border changes, transition timing, or anything that normally only shows up on interaction without needing another pair of hands to hold it there.

Tip 💡
Focus states are where this becomes especially important for accessibility. :focus and :focus-visible styles are frequently missing or inconsistently applied. With Force Element State, you can check focus ring visibility and contrast without tabbing through the entire page each time.

Visual CSS Editors That Don’t Require Writing Code

When certain CSS properties are applied to an element, DevTools surfaces visual editors right inside the Styles pane.

You only need to point and click; there’s nothing to type:

• Box shadow editor: Click the small square icon next to any box-shadow value and a GUI opens — drag the offset, blur, and spread values visually
• Color picker: Click any color swatch in Styles to open a full color picker with HEX, RGB, and HSL modes, an eyedropper for sampling any pixel on the page, and a contrast ratio readout
• Flexbox editor: When an element uses display: flex, a small “flex” badge appears next to the property in Styles. Click it, and a visual toolbar opens with alignment options as clickable icons — no CSS knowledge needed to test how things align

These are useful for communicating fixes precisely.

Saying: “The shadow blur should be 12px, not 4px” is a much more actionable bug report than “the shadow looks off.”

The Rendering Tab: Test Accessibility and Real User Conditions

The Rendering tab is full of simulation tools, things that change how the page looks or behaves based on different user conditions. Most of these have nothing to do with code.

This is the one feature designers (and most developers) are consistently surprised to find.

To open it: three-dot menu in DevTools (top right) → More tools → Rendering. Or use the Command Menu and type “Rendering.”

How to See Your Design the Way Color-Blind Users Actually See It

Under “Emulate vision deficiencies,” there’s a dropdown with options that re-render your entire browser window to simulate what different users see:

• Blurred vision: reduced visual acuity
• Protanopia: can’t perceive red light
• Deuteranopia: can’t perceive green light — the most common form of color blindness, affecting roughly 1 in 12 men
• Tritanopia: can’t perceive blue light
• Achromatopsia: no color perception at all, only shades of grey

Select one, and the whole page shifts without a plugin, export, or separate tool.

Over 300 million people worldwide have some form of color vision deficiency. When your UI uses color alone to communicate meaning—red for errors, green for success, color-coded tags with no other differentiator—a significant portion of users may not be able to tell what’s what.

Switch to Deuteranopia on your current project and look at your error and success states. If they look identical, that’s a real problem 💁‍♀️

But finding the problem is only half of it. What do you actually do about it?

Did you actually take a look and find issues, but you can’t even imagine how to solve them? The good news is the fix doesn’t have to mean designing and implementing five different color variations for every interactive state.

Here’s a straightforward principle: don’t let color be the only signal.

A few practical approaches that scale without creating chaos:

• Add an icon alongside color: An ✕ icon on error states, a ✓ on success. The color reinforces it; the icon carries the meaning. This holds up across all vision types.
• Use text labels: “Error” or “Success” as visible text rather than relying on a red or green badge alone. Simple, accessible, and easy to implement consistently.
• Change shape or weight, not just color: An error input that gains a thicker border, not just a red one. A disabled button that’s visibly different in shape or opacity, not just muted in color.
• Use patterns or textures in data visualizations: For color-coded charts or graphs, adding a pattern fill means the segments stay distinguishable when color is removed.

None of these requires redesigning everything. They’re small additions to what’s already there.

The goal is to ensure that if someone strips the color out of your UI entirely, it still makes sense.

Without necessarily adding considerable scope bloat to your design work, nor to the accompanying dev work.

Tip 👀
Combine vision deficiency emulation with the color picker’s contrast ratio indicator. If a text color fails the WCAG contrast check and looks indistinguishable from its background under Deuteranopia, that’s a high-priority accessibility fix, not optional.

A Bigger Point About What Accessibility Actually Means

Accessibility isn’t just about ARIA attributes in the markup or making sure a screen reader can navigate the page. That’s a part of it, but it’s not the whole picture.

It’s also about people with different visual abilities being able to use what you’ve built to distinguish states, read text, understand what’s interactive and what isn’t.

That concern gets pushed to the bottom of the list when teams are moving fast, but it should have been in the design from the start, not bolted on at the end.

The Rendering tab doesn’t fix that problem by itself. What it does is make the gap visible, fast. Most of the time, seeing it is all the motivation you need to address it.

Note 💬
There’s a misconception that accessibility is a dev-only implementation concern when, in fact, a designer should never hand off a design without accounting for accessible use. As a designer, you are the one responsible for the visual appeal and user experience of the UI you create.

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

How to Test Dark Mode and Other User Preferences Without Changing Your System Settings

Designers building for dark mode usually end up toggling their OS settings back and forth to preview results. The Rendering tab makes that unnecessary.

Under “Emulate CSS media feature prefers-color-scheme“, switch between light and dark without changing anything on your device.

If your page has a dark mode implementation, it flips instantly.

Other useful emulations in the same panel:

• prefers-reduced-motion: Shows what users see when they’ve asked their OS for less animation. It’s useful for verifying that fallbacks exist for motion-sensitive users
• prefers-contrast: Simulates a preference for higher-contrast display
• forced-colors: Simulates Windows High Contrast mode, where the OS overrides your color palette with system defaults. If your UI breaks or becomes unreadable here, that’s worth knowing before it ships

These are real preferences that real users set. Designing and testing for them is part of the job.

Device Mode: What It Does Beyond Basic Resizing

Most people know the Device Mode toolbar, the phone icon in the top-left of DevTools.

When you click it, the page goes mobile. If that’s as far as you’ve ever gotten, keep reading 👇

Why Device Pixel Ratio Actually Matters for Image and Layout Decisions

The device dropdown in Device Mode doesn’t just set a width. It also sets the device pixel ratio (DPR).

DPR affects how images render. A standard screen maps one CSS pixel to one physical pixel, but an iPhone 15 Pro has a DPR of 3, meaning one CSS pixel becomes three physical pixels.

What this means for you: An image that looks sharp on a laptop can appear soft or undersized on a high-DPR device if it’s not served at the right resolution.

Selecting a real device from the dropdown automatically applies the correct DPR.

You’re not just previewing width but also how image rendering actually works on that device.

That distinction matters when you’re specifying image dimensions or checking photography quality.

Adding a Device Frame to Your Preview

Three-dot menu in the Device Mode toolbar → Show device frame. Chrome wraps the viewport in a realistic phone or tablet bezel!

It’s useful for client presentations, handoff documentation, and design reviews.

You can also capture a screenshot that includes the frame.

Seeing Your CSS Breakpoints Visually as You Resize

In Device Mode, drag the blue handles to resize the viewport freely. The dimensions update live in the toolbar.

Most people miss that the bar at the top of the page shows an orange dot at every breakpoint defined in your CSS.

Drag toward mobile and watch where the layout shifts. Each orange dot is a breakpoint.

If a layout collapses awkwardly at a particular width, you can pinpoint it exactly—no stylesheet reading required.

Tip 🔥
The Edit option in the device dropdown lets you add custom device configurations. If your project has a specific target device that isn’t in the default list, you can add its exact width, height, and DPR.

The Animations Panel: Slow Down Any Transition to Inspect It

If you’ve ever tried to catch a detail in a transition that runs in a fraction of a second and just given up, this panel exists for that.

Open it via Command Menu → type “Animations” → Show Animations.

Trigger any animation on the page (hover over something, open a modal, click a button), and the panel captures it as a timeline. From there, you can:

• Scrub through the animation frame by frame using the playhead
• Slow down to 10%, 25%, or 50% speed using the controls in the panel header
• Pause and replay any captured animation
• See the easing curve for each animated property

The easing curve view is useful for implementation QA. A linear ease on a button that was designed with ease-out makes the interaction feel slightly off in a way that’s hard to explain.

Luckily, the Animations panel makes it visible. You can also edit timing values (duration, delay, easing) directly in the panel and see the result live.

No code change, no re-deploy.

Note: The panel captures animations as they happen. For hover animations, hover the element and the recording starts. Hit Ctrl+R inside the panel to clear and re-record.

The Sources Panel: Download Original Assets from Any Page

The Sources panel file tree shows every resource loaded by the page, from HTML, CSS, and JavaScript to images, fonts, and everything.

For designers, the practical use is this: you can download original assets directly from a live site.

Navigate the file tree to any image or font → right-click → Save as. Chrome downloads the original file at its original resolution.

It’s useful for competitive research, mood boards, verifying what file is actually being served (helpful when there’s a discrepancy between what was designed and what shipped), or situations where you need the live asset and the design file isn’t accessible.

Note ⚠️
Use this only on assets you have the right to access! Downloading from a site you don’t own for commercial use is a copyright issue. Research, reference, and internal QA are generally fine.

The CSS Overview Panel: Run a Design System Audit in 30 Seconds

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

What comes back is a visual report of everything in the stylesheet:

• Colors: every color value in use across the page, grouped visually. Near-duplicate greys that should be the same design token but aren’t show up as two separate swatches sitting next to each other
• Font info: every font family, weight, and size is actually rendered on page load
• Unused declarations: CSS rules that exist but aren’t applied to anything visible

Run it on a new feature build, and you’ll immediately see if a developer introduced a non-standard color or a font weight that isn’t in the spec.

Tip 💡
Run CSS Overview on your design system’s component library page. If the Colors section shows 11 shades of grey when your system only defines 4, you’ve found an inconsistency worth cleaning up.

Related: How I Built A Free Chrome Extension For Design Research

Five Things Worth Trying Today

Try these with no setup and no prior DevTools experience needed 👇

1. Make Any Page’s Text Editable

Open the Console tab in DevTools and type:

document.designMode = 'on'

Press Enter. The entire page becomes editable like a document.

Click any text and type over it. Test a shorter CTA. See if a longer headline breaks the container it lives in.

It’s the fastest way to prototype copy changes on a live page without touching Figma.

Turn it off:

document.designMode = 'off'

2. Screenshot Any Single Element, Perfectly Cropped

In the Elements panel, right-click any element in the DOM tree → Capture node screenshot.

Chrome downloads a PNG cropped precisely to that element’s rendered dimensions. No surrounding content, no browser chrome—just the element.

It’s useful for bug reports, component documentation, and design review comparisons against a spec.

For a full-page capture including below-the-fold content: Command Menu → “Capture full size screenshot.”

3. Lock a Hover or Focus State in Place

In the Elements panel, select any interactive element. In the Styles pane, click :hov → check :hover or :focus.

The element stays in that state while you inspect everything about it.

Contrast, colors, borders, spacing—all are inspectable without the state disappearing when you move your mouse.

4. See How Your UI Looks to Someone with Color Blindness

Rendering tab → Emulate vision deficiencies → Deuteranopia.

Look at your interface:

• Can you still tell which elements are interactive?
• Do your error and success states look different from each other?
• Can you read all the body text?

If something becomes unclear or invisible, you’ve found a real accessibility issue in under a minute, without any external tool.

5. Audit Your Colors and Fonts in One Click

Command Menu → “CSS Overview” → Capture overview → open the Colors tab.

Count the greys. Check the font weights. Compare against what’s in the design system.

Thirty seconds and you’ll know if something slipped through.

Extensions That Close the Gap Between DevTools and Your Design Workflow

Though DevTools covers a lot on its own, for some workflows, there are a few extensions worth adding.

These are some that kept popping up:

ColorZilla: Click any pixel on the page and copy the exact HEX, RGB, or HSL value. Also reads background gradients directly from elements. Faster than opening DevTools for a quick color check.

WhatFont: Hover over any text and get the typeface, weight, size, and line height instantly. Reads from the browser’s rendered output, so it reflects what’s actually applied.

Pixelay: Overlays a Figma frame on top of a live webpage as a semi-transparent layer. Compare design spec and implementation side by side at the pixel level, in the same view. One of the fastest QA approaches available for teams working in Figma.

Inspo AI: Captures and organizes UI inspiration directly from the browser, instead of a folder of unmanageable screenshots. Worth it if you’re maintaining a reference library or regularly building mood boards.

Tip: Install what you’ll actually use and check the permissions each extension requests. A small, intentional set of tools beats a cluttered toolbar.

A Design QA Workflow, Start to Finish

Now, let’s put everything above in one practical sequence. You’ve just received a new feature build, and you’re doing a design QA pass before it goes live.

Step 1: Inspect the basics

Open DevTools → Ctrl+Shift+C → hover over key elements and check fonts, sizes, and spacing against the spec.

For anything off, click to select → Computed tab → find the actual resolved value.

Step 2: Check interactive states

For every interactive element, use :hov to lock in hover and focus states and compare against the design.

Focus states are the most commonly skipped, so make sure to check them.

Step 3: Accessibility pass

Rendering tab → Emulate vision deficiencies → run through at least Deuteranopia and blurred vision.

Use the color picker’s contrast ratio indicator on your primary text colors. Below 4.5:1 is a WCAG AA failure for normal-sized text.

Feel free to use THT’s free SEO & Accessibility Helper and DIRA Chrome extensions to help out!

Note 📍
This step verifies that the accessibility decisions made during design were implemented correctly. Get that? It assumes those decisions were made. That your designs included distinct states, sufficient contrast, and non-color differentiators to begin with. If that foundation isn’t there, what you’re looking at here isn’t a developer implementation problem; it’s a design problem that needs to go back a step.

Step 4: Responsive check

Device Mode → select key target devices → check layouts at breakpoints.

Watch the orange breakpoint markers and verify behavior at each transition point.

Step 5: Quick CSS audit

Command Menu → CSS Overview → Capture overview → check colors and fonts against the design system.

Flag anything that doesn’t belong.

Step 6: Document issues precisely

Right-click the problem element in Elements → Capture node screenshot → attach to the bug report with the exact value: “padding-top on .hero-cta should be 24px, currently 16px.”

Take it from a dev: that’s fixable in 60 seconds. “The button looks off” is not.

It’s a Wrap

Chrome DevTools gives you access to the actual source of truth, that is, the live page, resolved values, and real behavior.

Not a static spec, not a screenshot, not a design file that may or may not reflect what’s in production.

You don’t need a JavaScript background to use most of this. You need the browser you already have and some willingness to poke around.

If you want a single place to start: press Ctrl+Shift+C, hover over something on any page, and read what the tooltip tells you.

That’s the same thing that caught my attention in that designer’s reference screenshot. It’s simple, it’s fast, and once you’ve used it, you’ll wonder how you were eyeballing things before.

And the next time you file a bug report, take a node screenshot with the exact CSS value, done.

Developers notice that kind of specificity. It gets fixed faster!

Hope this helped someone 👍