Chrome Developer Tools: The Ultimate Overview

Chrome developer tools, or Chrome DevTools, give us a window on how our websites working in the wild. Built for developers of all experience grades, they provide powerful ways to inspect, debug and optimize our projects.

However the sheer breadth of functionality can be a mind-melt if you’ve not worked with DevTools before, and there are lots of advanced features that even experienced users find tricky.

So we thought we’d publish a dedicated post, both to unpack Chrome DevTools and take you through each individual feature in detail. The post is designed to cover all the essential stuff you’ll encounter in your day-to-day, but if you’re here for a specific piece of knowledge, jump to it below.

So what are Chrome developer tools, exactly?

in the simplest terms, Chrome Developer Tools are a built-in set of tools included in the Google Chrome browser, and they help developers understand how a website behaves directly in the browser.

More specifically, Chrome DevTools allow us to:

• Inspect HTML structure and CSS styles.
• View errors, warnings, and console output.
• Monitor network requests and loaded resources.
• Measure performance and page speed.
• Simulate devices, screen sizes, and environments.

DevTools are handily organized into multiple panels, each focused on a specific aspect of web development and testing.

How to open Chrome developer tools

Chrome developer tools can be opened directly from the Chrome browser in lots of ways. But here are the most common methods, step by step:

• Open Chrome and load any web page you want.
• Right-click anywhere on the page and select Inspect.
• Chrome DevTools will open docked to the page.

Alternative methods:

• Keyboard shortcut
  • Windows or Linux: F12 or Ctrl + Shift + I
  • macOS: Cmd + Option + I
• Chrome menu
  • Click the three dots in the top right.
  • Go to More tools.
  • Select Developer tools.

Once opened, DevTools can be docked, undocked, or moved to a separate window.

An introduction to Google Chrome DevTools panels

If we were pitching Chrome DevTools to a potential investors, the simplicity of the hierarchy would be the first thing we’d emphasize.

Chome DevTools are organized into multiple panels, each focused on a specific part of how a web page loads, renders, and behaves. The deeper you go with DevTools, the more useful this functionality becomes.

The table below summarizes the main panels available in DevTools and what each one is used for, at a very high level.

Main Panels	What we can inspect or find
Elements	DOM structure, applied CSS, layout, box model, grid and flex overlays
Console	Runtime JavaScript output, errors, warnings, and interactive execution
Sources	Loaded source files, execution flow, breakpoints, scopes, overrides
Network	Requests, responses, headers, payloads, timing, loading order
Performance	Rendering timeline, scripting, layout shifts, long tasks
Memory	Heap usage, allocations, detached nodes, memory leaks
Application	Storage, cookies, caches, service workers, app metadata
Security	HTTPS status, certificates, mixed content issues
Lighthouse	Automated audits for performance, accessibility, best practices, SEO

---

Got that? Cool. Now, let’s unpack.

Elements Panel

What we use the Elements panel for

The Elements panel is our primary visual inspection surface. It’s where we inspect the live structure and styling of the page as it exists right now and it reflects the rendered DOM, not the original HTML file, including dynamic changes made by JavaScript.

As developers we use this panel to understand why an element looks, behaves or is structured the way it is, and to test visual or structural changes directly in the browser. It’s great for answering questions like “what is this element really?”, “why does it look like this?”, and “what changed it?” before we move into code execution or network behavior.

Note that all edits here are temporary and apply only to the current session.

What we see and where to look

Area (visibility order)	What it shows	We use it when…
DOM tree (left panel)	Live HTML structure of the page.	We need to locate elements, verify nesting, or confirm whether nodes are added or removed dynamically.
Styles	CSS rules applied to the selected element.	Styles look wrong, overridden, or unexpectedly inherited.
Computed	Final calculated CSS values after cascade and inheritance.	We need the actual applied value (e.g. real display, width or color).
Layout	Flexbox and Grid helpers, alignment overlays, and spacing visualization.	The layout or alignment feels off.
Event Listeners	JavaScript events attached to the element.	Clicks, hovers, or inputs do nothing.
DOM Breakpoints	Pause execution when the DOM changes.	Elements change, disappear, or re-render unexpectedly.
Properties	JavaScript properties linked to the DOM node.	Element state or references feel inconsistent.
Accessibility	ARIA roles, labels, and accessibility metadata.	We need to check semantics of a11y (accesssibility) behavior.

The Font Editor in Elements

The Font Editor lives inside the Styles pane of the Elements panel. We typically use it for quick typography tuning, readability checks, and layout-sensitive font adjustments during inspection and debugging.

It’s an experimental Chrome DevTools feature and is disabled by default. In other words, you’ve got to explicitly turn it on before it appears.

How to enable the Font Editor

• Open Chrome DevTools.
• Click the Settings icon (⚙️) in the top-right.
• Go to Experiments.
• Enable New font editor in the Styles pane.
• Close and reopen DevTools to apply the change.

Once enabled, an “A” icon becomes available next to the font-related CSS properties.

How to use the Font Editor

• Select an element in the Elements panel.
• Open the Styles pane on the right.
• Locate a rule with font properties (font-size, font-weight, line-height, letter-spacing).
• Click the A icon to open the Font Editor.
• Adjust values using the visual controls.

Note that you can observe changes live on the page, without editing source files.

Copy CSS Declaration in Elementor

The Copy CSS declaration feature is another key part of Elements that you should know about. It lets us extract the exact cascading style sheets (CSS) applied to an element without manually rewriting it, and it captures property names and values as they are defined in the rule, so it’s easy to reuse styles elsewhere or share them with teammates.

Action	What it’s useful for
Copy declaration	Reuse single CSS properties quickly
Copy rule	Duplicate a full selector with properties
Copy all declarations	Extract all styles applied in a rule block
Paste into editor	Move styles into stylesheets or components
Share snippets	Send exact styling details in reviews or bug reports

We often rely on this feature when refactoring styles, migrating CSS into components, or documenting visual changes without guessing property values.

How to use it

• Open Elements and select an element in the DOM tree.
• In the Styles panel, right-click on a CSS rule or selector.
• Choose Copy → Copy declaration (or Copy rule / Copy all declarations).

---

Console Panel

What we use the Console Panel for

The Console Panel is typically the first place we look when something fails, behaves unexpectedly, or reports runtime issues during execution.

This is where we observe runtime behavior and interact directly with JavaScript execution in the current page context. It continuously reflects what the browser and page scripts are doing, revealing errors, warnings, and informational messages as they happen.

We also use it as a live JavaScript prompt to evaluate expressions, inspect values and quickly test assumptions against the current page state.

Area	What it shows and when we use it
Console messages (main area)	Runtime errors, warnings, and logs emitted by scripts or the browser.
Message levels & counters (left sidebar)	Error, warning, and log counts; useful to quickly assess severity.
Message grouping (left sidebar)	Grouped or repeated messages to reduce visual noise.
Filters (top bar)	Filter messages by level, text, or source when logs become noisy.
JavaScript prompt (bottom input)	Run JavaScript expressions directly in the current page context.
Object inspection (▶)	Expand objects, arrays, DOM nodes, and errors to inspect structure.
Live expression watch (eye icon)	Pin expressions and re-evaluate them automatically as state changes.

Want a deeper dive into logging-specific usage and message output? We’ll cover this in more detail in our guide on JavaScript console log.

Sources panel

What we use the Sources panel for

The Sources panel allows us to inspect loaded source files and observe JavaScript execution while it runs.

It’s where we pause code, inspect state, and understand execution flow, including async behavior.

Area	What it shows	We use it to….
File navigator (left)	All loaded source files, grouped by origin.	Locate scripts, bundled assets, or dynamically loaded files.
Editor view (center)	Source code of the selected file.	Read code, set breakpoints and step through execution.
Watch (right)	Manually tracked expressions.	Monitor variables or computed values while stepping through code.
Breakpoints	Line breakpoints and pause settings (including pause on exceptions).	Stop at the exact moment code fails or misbehaves.
Scope	Local, closure, and global variables.	Inspect these variables at the paused moment.
Call stack	The sequence of function calls that led to the current execution point.	Understand and trace how our JavaScript code is executing at a specific moment in time.
XHR / fetch breakpoints	The exact chain of functions that led to the request when execution pauses on an XHR or fetch() breakpoint.	Pause JavaScript execution exactly when a network request is made, so we can see what code triggered the request and why.
DOM breakpoints	When and where JavaScript code changes the DOM, and what code caused that change.	Pause when DOM nodes change (subtree, attributes, removal).
Global listeners	A list of registered event types and handlers.	Perform a check when events fire from unexpected places.
Event listener breakpoints	The point when specific event categories fire (click, input, keydown, etc).	Pause execution when an event fires, so we can see which code responds to the event and why it behaves the way it does.
CSP violation breakpoints	When a page violates its Content Security Policy (CSP).	Pause when Content Security Policy blocks a script/resource. Useful for debugging blocked scripts or workers.
Overrides	Local versions of files (HTML, CSS, JS, images, headers, or responses) that replace what the browser normally loads from the server, without changing the real backend or source code.	Replace loaded files with local versions to test changes without redeploying.
Source maps	The relationship between transformed code (minified, bundled, or transpiled) and the original source code that developers actually wrote.	Map bundled or minified code back to original source files.

If you want to dig into async-related behavior that’s harder to reason about step-by-step, no problem: we’ve got a whole dedicated post on Asynchronous JavaScript.

---

Network Panel

What we use the Network Panel for

The Network panel allows us to inspect all network activity triggered by a web page. It’s particularly useful when when requests fail, data looks incorrect, or page loading feels slow or inconsistent.

We can utilise this panel to show how resources are requested, transferred and loaded, making it easier to understand what the browser is downloading and how long each step takes. Crucially it reflects real requests made by the page, including API calls, static assets, and background fetches.

Area	What it shows	We use this to…
Request list	All network requests made by the page.	See what loads and in what order.
Headers	Request and response headers.	Debug authentication, caching or CORS issues.
Payload tab	Data sent with requests.	Perform a check when API calls fail or send unexpected values.
Response	Server responses.	Perform an inspection to verify returned data or error messages.
Timing	A detailed timing breakdown.	Identify slow or blocking requests.
Waterfall	A visual request timeline.	Spot bottlenecks and load dependencies
Throttling	Simulate slower network conditions.	Test how the page behaves on poor connections.
Offline mode	Disabled network access.	Verify offline or fallback behavior.

The Payload Tab on the Network Panel

The Payload tab shows the data sent with a network request. Specifically, it lets us inspect query parameters, form data, and request bodies exactly as they are transmitted by the browser.

This view is especially useful when API requests fail, return unexpected results, or behave differently than expected. By checking the payload, we can confirm the data that was actually sent, not what we assumed was sent.

The Payload tab helps us quickly answer “are we sending the right data to the server?” before looking at responses, headers, or backend logic.

CORS errors

CORS errors tell us that a browser request was blocked due to cross-origin rules. This is vital to our wider debugging strategy, as it allows us to answer “why did the browser block this request?” and determine whether the fix belongs in server headers, request setup, or environment configuration.

These errors occur when a web page tries to access a resource from a different origin that is not explicitly allowed by the server. In the Network panel, we can identify CORS issues by inspecting failed requests, their response headers, and related error messages.

---

Performance Panel

What we use the Performance Panel for

The Performance Panel gives us great insights when our page feels slow, clunky or unstable, even if no actual errors are reported.

Its functionality enables us to record, measure, and analyze how a page loads and responds to user interactions; the insights also give us a vital window on the main thread, revealing why rendering feels slow and isolating the parts of the page that cause visual or interaction issues.

Unlike Network or Console, this panel focuses on time-based behavior: rendering, scripting, layout and user experience metrics, all observed while the page runs.

Area	What it shows	We use it to…
Live metrics	The entry point of the panel.	Show local performance metrics while interacting with the page.
Largest Contentful Paint (LCP)	The time taken by the main visible content to finish loading.	Check when pages feel slow to appear.
Cumulative Layout Shift (CLS)	Unexpected layout movement.	Take a check when elements jump or shift during load.
Interaction to Next Paint (INP)	Responsiveness to user input.	Check when clicks or typing feel delayed.
LCP element reference	Which DOM element defines LCP.	Identify slow images or blocks.
Interactions / Layout shifts tabs	A breakdown of user actions and visual instability events over time.	Examine our users’ behavior and evaluate our site’s response.
Screenshots toggle	Visual frames during recording.	Correlate timing with what we actually see.
Memory toggle	Memory usage data in addition to the regular recording.	Check performance degrades over time.
Dim 3rd parties	Which scripts and resources come from third-party domains (visually de-emphasized for extra clarity).	Isolate the impact of our own code.
Environment settings	The conditions under which the performance recording was captured (with specific reference to timing, CPU usage and rendering behavior).	Configure CPU and network throttling to simulate real user conditions.
Disable network cache	Only fresh network requests fetched directly from the server (not responses served from the browser’s cache).	Test cold-load performance.
Record	A detailed timeline of everything the browser does while the page runs.	Analyze where time is spent and why the page feels slow or clunky.
Record and reload	Everything the browser does during a full page load, from the moment navigation starts until the page finishes loading.	Analyze and optimize real page-load performance, not just interactions after the page is already open.

Want a step-by-step walkthrough focused on performance analysis? See How to debug your site performance with Chrome

---

Memory Panel

What we use the Memory Panel for

As our websites scale, it’s normal for memory usage to increase over time, pages to slow down after extended use and crashes to occur during long sessions. This is where the Memory Panel comes into its own.

The Memory Panel helps us analyze how JavaScript and DOM objects are allocated, retained and released at runtime. It is particularly good at detecting memory leaks, understanding long-lived objects and investigating the memory creep that we might miss ourselves.

Note that the panel focuses on profiling strategies first, then execution context, and only afterward on results and analysis. This mirrors the actual DevTools layout and flow.

Area	What it shows	We use it to…
Selecting profiling type	The kind of memory analysis Chrome will capture and display.	Choose how memory is analyzed (actually this should be the first decision we make before running any analysis).
Heap snapshot	A point-in-time snapshot of all JavaScript objects and related DOM nodes.	Find retained objects and compare snapshots.
Allocations on timeline	How JavaScript memory is allocated and released over time while the app runs.	Track allocations over time and highlights objects still alive, which is particularly useful when memory grows during interactions.
Allocation sampling	A low-overhead sampling of allocation hotspots.	Spot general sources of memory usage.
Detached elements	DOM nodes removed from the document but still retained by JavaScript references,	Isolate and identify problems with DOM nodes, a common source of UI memory leaks.
Select JavaScript VM instance	How Chrome (via the V8 engine) has isolated, executed, and managed JavaScript code.	Inspect specific execution contexts (main page, iframe, worker); critical when issues occur only in specific contexts.
Profile results view	The collected data, based on the selected profiling type.	Turn low-level execution data into actionable insights about cost, hotspots, and bottlenecks.
Total JS heap size indicator	A live view of current heap size and growth rate.	Observe and track JavaScript memory usage over time, mainly to spot abnormal memory growth and potential leaks.
Load profile / Take snapshot controls	How JavaScript uses CPU or memory, captured at a specific moment or over a period of time.	Start or load a memory analysis session.

Application Panel

What we use the Application Panel for

The Application Panel is crucial for diagnosing persistence, caching, and PWA-related issues. It’s particularly useful when issues are not visible in the UI or console, but come from the less obvious stuff: the cached data, service workers, storage, or app configuration.

With the Application Panel, we get a glimpse of how the browser retains state and manages app-level features. This in turn allows us to focus on how our app stores data, registers background capabilities and defines installable or progressive features.

Area	What it shows	We use it when…
Manifest	Web app metadata such as name, icons, theme, and installability.	The PWA install or appearance is incorrect.
Service workers	Registered service workers and lifecycle state.	Offline support, caching, or updates behave unexpectedly.
Storage (Client-side)	Local, session, IndexedDB, cookie and cache storage.	Data seems stale, missing, or inconsistent.
Background services	Push, sync, fetch, and scheduled tasks.	Background actions fail or don’t trigger.
Back/forward cache	Page restoration behavior.	Navigation state breaks after back or forward actions.
Frames	Storage and execution context per frame.	We’re dealing with iframes or embedded content.

Before we move on to the next panel, let’s dig into some of these areas as they’re essential to navigating the Application Panel properly.

Manifest

The Manifest section controls how our web app is identified and installed by the browser. It shows the parsed contents of manifest.json exactly as Chrome understands it.

If an install prompt is missing or the installed app looks wrong, this is the first place to check.

We typically use Manifest to:

• Verify app identity, specifically the app name, short name and description used during installation.
• Check installability, notably whether the app meets PWA requirements and can be installed.
• Inspect visual presentation. We’re referring to icons, theme color, background color and display mode.
• Validate startup behavior, looking closely at the start URL and orientation when the app is launched.

Service Workers

Service Workers shows how our app behaves offline and in the background. Specifically, it exposes the lifecycle and state of registered service workers for the current site.

When offline mode does not work, updates are stuck, or cached content behaves unexpectedly, this is the first place to investigate.

We typically use Service Workers to:

• Verify service worker registration, specifically active, waiting, or redundant workers.
• Control caching behavior, inspecting and debugging assets cached for offline use.
• Test updates safely, with the power to skip waiting, unregister or force updates during development.
• Debug background features like push notifications, background sync and fetch handling.

Storage

When our app behaves correctly after a refresh but breaks later, Storage is often the root cause and the fastest place to confirm it.

Using Storage, we can inspect and manage all client-side data stored by the browser for the current site. The really cool thing is that it groups multiple storage mechanisms in one place.

We typically use Storage to:

• Inspect stored data like local Storage, Session Storage, IndexedDB and cookies.
• Verify persisted state: user settings, feature flags and auth tokens.
• Debug data-related issues such as stale values, unexpected persistence or missing keys.
• Clear storage safely, without redeploying or hard refreshes.

Privacy and Security

The Privacy and Security Panel is essential when something “should work” but fails due to browser privacy rules or origin security context. It shows how the browser applies privacy restrictions and origin security to the current page.

Armed with this data, we can confirm whether failures come from cookie limits, third-party contexts or insecure origins, not from our code.

Area (where)	What it shows	We use it when…
Controls (Left)	Privacy controls navigation.	We need to test cookie restrictions quickly.
Third-party cookies	Cookie restriction settings and scenarios.	We want to check embeds, login flows or analytics break.
Security overview	High-level security state.	The browser shows warnings or blocked content.
Secure origins	List of origins and whether they’re secure.	Third-party origins or iframes behave differently.
Controls (Right)	The actual toggles and exception.	We want to reproduce third-party cookie issues without leaving DevTools.

Lighthouse

The Lighthouse Panel is really useful when we need a high-level health check of a page, especially before releases or when tracking regressions across performance, accessibility, and SEO.

Importantly, it lets run automated audits against the current page and get actionable reports across performance, accessibility, best practices and SEO. It simulates real usage conditions and produces a structured report that highlights issues, explains impact, and suggests concrete fixes.

Area (where)	What it shows	We use it to…
Mode	Navigation, Timespan, or Snapshot.	Perform a full-page load audit, check interaction over time or consult a static state.
Device	Mobile or Desktop simulation;	Compare mobile-first vs desktop behavior.
Categories	Performance, Accessibility, Best Practices, SEO.	Select what we want Lighthouse to audit.
Analyze page load (top right)	The start of the audit.	Reload or inspect the page automatically.
Report view (after run)	Scores, metrics, and recommendations.	Identify bottlenecks and prioritize fixes.
Diagnostics and opportunities	Detailed findings with explanations and estimated impact.	Identify priorities and decide what to fix first.

A quick note on device emulation

Device emulation lets us simulate how a page renders and behaves on different devices directly inside the browser. It affects viewport size, input method, pixel density, and performance constraints, making it ideal for fast mobile checks without external tools or real devices.

We typically use device emulation to reproduce mobile-only bugs, validate responsive layouts, and test real-world performance conditions without leaving DevTools.

How to open it

• Click the tablet + phone icon in the top-left corner of DevTools, just above the Elements panel, or
• Press Cmd + Shift + M (macOS) / Ctrl + Shift + M (Windows).

Once enabled, the page switches into responsive mode, and a device toolbar appears above the page preview.

Control	What we use it for
Device selector	Switch between preset devices (iPhone, Pixel, iPad).
Viewport size fields	Manually set width and height to test breakpoints.
Rotate button	Toggle portrait / landscape orientation.
Device pixel ratio (DPR)	Inspect high-DPI rendering issues.
Zoom level	Check layout scaling and text readability.
Touch simulation	Enable touch input for gesture testing.
Network throttling	Simulate slow mobile networks (3G, 4G).
CPU throttling	Reproduce performance issues on weaker devices.
Hide device frame	Focus purely on content and layout.

More Chrome DevTools

Some Chrome DevTools panels are not visible by default and are grouped under More tools.

These are task-specific utilities that we open only when we need deeper inspection, performance analysis, or experimental features, and they live inside the DevTools drawer at the bottom.

How to open these tools

• Open DevTools.
• Click the ⋮ (three-dot menu) in the top-right corner.
• Select More tools.
• Choose the panel you need from the list.

Note: tools open as new tabs inside DevTools and stay available for the current session.

Tool	What we use it for
AI assistance (Chrome only)	Get inline explanations, fixes, and suggestions for CSS, performance, and accessibility issues.
Animations	Inspect and debug CSS animations and transitions frame by frame.
Autofill	Test and debug browser autofill behavior for forms.
Changes	Track CSS and DOM edits made in DevTools and copy them back to code.
Coverage	Find unused CSS and JavaScript to reduce bundle size.
CSS Overview	Get a global snapshot of CSS usage, colors, fonts, and contrast.
Developer resources	Inspect loaded resources, source maps, and attribution.
Issues	Get a centralized view of browser-detected problems (CSP, deprecations, breaking changes).
Layers	Inspect composited layers created by transforms and animations.
Media	Debug media playback, codecs, and streaming issues.
Memory inspector	Inspect raw memory buffers and low-level memory.
Network conditions	Simulate offline mode, latency, and bandwidth limits.
Network request blocking	Block requests to test failure and fallback scenarios.
Performance monitor	View live CPU, memory, DOM nodes, and FPS metrics.
Privacy and security (Top-level panel)	Inspect privacy controls, cookie behavior, and secure origins.
Quick source	Open ephemeral or evaluated sources.
Recorder	Record and replay user interaction flows.
Rendering	Enable visual debugging overlays (paint flashing, layout shifts, FPS).
Search	Run project-wide search across all loaded sources.
Sensors	Emulate geolocation, orientation, and motion sensors.
WebAudio	Debug Web Audio API graphs and nodes.
WebAuthn	Test passkeys and authentication flows.
What’s new	View DevTools release notes and recent updates.

We’re not going to explore all of these tools. That’s beyond the scope of a single article. Instead, let’s look at the tools which are most likely to impact your daily work.

CSS Overview

CSS Overview gives us a high-level audit of all CSS used on the page. Instead of inspecting styles element-by-element, it summarizes colors, fonts, unused declarations and potential consistency issues in one place.

We typically use CSS Overview to clean up bloated stylesheets, enforce design consistency, and spot CSS problems early, before they spiral into layout or maintenance issues.

How to open it

• Open Command Menu with Cmd + Shift + P (macOS) / Ctrl + Shift + P (Windows).
• Type “CSS Overview” and select Show CSS Overview.
• Click Capture overview to scan the current page.

Section	What we use it for
Colors	Identify duplicate, similar, or inconsistent colors
Font info	Review font families, sizes, weights, and usage spread
Unused declarations	Spot CSS rules not applied to any element
Media queries	Understand responsive breakpoints in use
Z-index values	Detect stacking conflicts and excessive z-index usage
Specificity issues	Find rules that may be overly specific or hard to override
Overview summary	Get a quick CSS health check of the page

---

Recorder Panel

The Recorder Panel complements other panels by handling what users do, while the rest of DevTools explains what the browser does in response.

We use Recorder to record clicks, inputs, and navigations exactly as they happen in the browser, empowering us to capture real user interactions and turn them into replayable, repeatable steps. Instead of manually reproducing the same sequence every time, we can record once and reuse, making it easier to debug multi-step issues, validate fixes, or create automated tests from real behavior.

Recorder is especially useful when issues:

• Require multiple steps to reproduce.
• Depend on timing or interaction order.
• Need to be shared clearly with other developers.
• Should be turned into automated regression tests.

Area	What it shows	We use it to…
Plus icon (top left)	Create a new recording.	Capture a fresh user flow.
Record control	Specific interactions like clicks, typing and navigation.	Begins recording interactions on the page.
Recording list (top bar)	Saved recordings.	Switch between different flows.
Replay controls	How a recorded user flow is played back and managed step by step.	Re-run a recording to reproduce the same behavior consistently.
Export options	How a recorded user flow can be converted and reused outside the Recorder.	Convert recordings into Playwright tests or reusable JSON steps.
Create recording (center)	The starting point for creating a new user flow.	Quick entry point when no recordings exist yet.

The panel focuses on flows and actions, not logs, DOM inspection or metrics.

Rendering Panel

The Rendering panel exposes visual rendering controls that affect how the page is painted and composited by the browser. It’s mainly used to simulate rendering conditions and surface visual issues that are otherwise hard to spot during normal inspection.

We typically open the Rendering panel when visual behavior looks correct in code but wrong on screen, or when validating accessibility, motion preferences, and rendering performance together. Note that it lives in the bottom drawer and is enabled via ⋮ → More tools → Rendering.

Control	What we use it for
Emulate CSS media features	Test media queries like prefers-color-scheme, prefers-reduced-motion, or forced-colors
Dark mode emulation	Verify dark / light theme behavior without changing OS settings
Emulate vision deficiencies	Preview how the UI appears with color blindness or low vision
Highlight paint flashing	Detect frequent repaints that may hurt performance
Highlight layout shifts	Spot unexpected layout movement during page load
Show FPS meter	Monitor frame rate stability during animations or scrolling
Show layer borders	Visualize composited layers and rendering boundaries

Dark mode emulation

Dark mode emulation allows us to simulate how a site behaves when the operating system is in dark mode. It triggers the prefers-color-scheme media query, letting us verify styles without changing system settings.

We can deploy dark mode emulation to fulfil a variety of specific functions: to validate theme support, catch contrast issues early, and ensure dark mode behaves correctly across components before shipping.

Control	What we use it for
prefers-color-scheme	Test dark vs light theme styles.
Live toggle	Instantly switch themes without reloading.
CSS media query	Validate @media (prefers-color-scheme) rules.
Color contrast	Catch low-contrast text or icons.
Background colors	Detect hardcoded light backgrounds.
Images & icons	Spot assets that don’t adapt to dark mode.

How to open it

• Open Command Menu with Cmd + Shift + P (macOS) / Ctrl + Shift + P (Windows).
• Search for “Rendering” and select Show Rendering.
• In the Rendering panel (bottom drawer), set Emulate CSS media feature → prefers-color-scheme.
• Choose Dark (or Light to switch back).

Chrome DevTools Settings

We access DevTools settings to shape how powerful and efficient DevTools feels day-to-day, especially when working across multiple projects or devices.Specifically, we can configure how DevTools behaves, enable optional features, and customize our debugging environment.

This panel doesn’t inspect a page directly. It controls preferences, devices, experiments, and AI-assisted features that affect all DevTools panels.

How to open DevTools settings

• Open Chrome DevTools.
• Click the gear icon (⚙️) in the top-right corner.
• or open the Command Menu (Cmd + Shift + P / Ctrl + Shift + P) and search for Settings.

Section	What we use it for
Preferences	UI behavior, theme, language, panel defaults, and general DevTools behavior.
Workspace	Map local files to DevTools so changes persist to disk.
AI innovations (Chrome only)	Enable AI assistance, console insights, code suggestions and performance annotations.
Experiments	Turn on experimental features (for example, the Font Editor).
Ignore list	Exclude files or libraries from debugging and stack traces.
Devices	Manage custom devices used in device emulation.
Throttling	Create custom network and CPU throttling profiles.
Locations	Define custom geolocations for location-based testing.
Shortcuts	View and customize keyboard shortcuts for DevTools.

Preferences

The Preferences section controls how Chrome DevTools behaves while we inspect and debug a page.

These settings don’t affect the website itself. Instead, they influence how information is displayed, recorded and assisted inside DevTools, helping to reduce noise and adapt the tools to different workflows.

Section	What it controls
Appearance	DevTools theme, panel layout behavior, UI language and visual readability options.
Network	Cache behavior, grouping of network activity, and how requests are logged and preserved.
Sources	Source maps, file discovery, editor helpers and debugging behavior for JavaScript.
Console	Log verbosity, grouping, timestamps, autocomplete behavior and warning visibility.
Performance	How flamecharts and performance visualizations are displayed during profiling.
Devices	Custom device definitions, used by device emulation for responsive testing.
Throttling	CPU and network throttling profiles used across DevTools panels.
Locations	Geolocation overrides to simulate different physical locations.
Workspace	Mapping local files so edits persist and reflect live during development.

Keep in mind that preferences are usually configured once per workflow, making everyday debugging faster and more predictable.

AI Innovations

The AI Innovations section groups experimental AI-powered features designed to speed up debugging, analysis, and code understanding directly inside DevTools. These tools assist with interpreting console output, inspecting styles and network data, annotating performance traces, and suggesting code while typing.

Feature	What it helps with
Console Insights	Explains console warnings and errors
AI assistance	Interprets CSS, network activity, files and performance data
Auto annotations	Adds readable labels to performance traces
Code suggestions	Suggests code in Console and Sources

Things to consider

• Some inspected data (console messages, stack traces, files, traces) may be sent for analysis.
• Data may be reviewed by humans to improve the feature.
• We shouldn’t enable on pages with sensitive or personal information.
• Features may vary by region or rollout stage.

These tools are best used as assistive helpers, not as a replacement for manual debugging.

Experiments

The Experiments section lets us enable early, in-progress DevTools features before they become stable. This area is primarily for testing, debugging, and exploring advanced capabilities, and it can change frequently as Chrome evolves.

Some commonly useful experiments include:

• New Font Editor, which unlocks visual font controls in the Styles pane.
• Full accessibility tree view, which exposes the complete accessibility structure.
• Capture node creation stacks, which helps trace where DOM nodes are created.
• Hide ignore-listed code, which reduces noise in the Sources panel.
• APCA contrast algorithm, which previews upcoming accessibility contrast rules.
• Protocol Monitor, which inspects low-level DevTools protocol traffic.

Because these features are experimental, be aware that options may disappear, move, or change behavior between releases. We’d advise enabling only what you actively need, and expect this section to evolve quickly over time.

Final thoughts: where DevTools stop, real debugging begins

Chrome DevTools are excellent for local inspection and top-level debugging. They help us understand what’s happening in the browser right now, so we can make fast fixes and pinpoint urgent issues.

But they stop being effective when issues:

• Happen only in production.
• Depend on real users, devices or timing.
• Are intermittent or asynchronous.
• Disappear when we try to reproduce them locally.

This is what Bugfender is for.

Bugfender complements DevTools with remote, persistent logs, real-world context, and visibility into issues that never show up locally. If DevTools are the microscope, Bugfender is the black box recorder.

So remember: Use DevTools to inspect. Use Bugfender to see what actually happens in the wild.