DevTools Debugging Tips And Shortcuts (Chrome, Firefox, Edge) — Smashing Magazine

Profiles That Fit the Job

Separate browser profiles have become a staple debugging technique. Rather than mixing regular use with debugging and testing work, a team can maintain several clean profiles — each with a purpose, and each in its own state of "danger":

• Accessibility profile runs accessibility linters and color vision simulators like Accessibility Insights, aXe and a11y.css alongside related audit tools.
• Debugging profile enables experimental settings, auto-opens DevTools in every new window, and injects a diagnostics CSS stylesheet for quick cookie-cutter auditing.
• Performance profile books only budget-oriented extensions and pages: Lighthouse, RequestMap, resource-priority references, plus a performance diagnostics stylesheet. The profile gets paired with 4× CPU throttling and Slow 3G network throttling.
• Happy customer, modeled after a typical reader's browsing setup: popular ad-blockers, web-dev extensions, tab management tools, Google Docs offline, LastPass, VPN, Browserstack, Grammarly. No throttling.
• Unhappy customer simulates worst-case conditions: slow 3G, low memory and CPU, 10 of the most common extensions loaded. This profile is what you test your heaviest pages against.

Profiles become work shortcuts: a debugging task starts by selecting a matching profile with the extensions, bookmarks, settings and throttling pre-installed. Caches, cookies and the extension set should stay clean and intentional.

Shortcuts Worth Remembering

Rather than hunting through panel menus, learn a few global shortcuts; they jump directly to common DevTools tasks in Chrome, Firefox, and Edge:

• Command Menu (Chrome, Edge): Cmd/Ctrl + Shift + P opens the searchable autocomplete for all panels and features. Use the same prefix with P alone to list page source files.
• Settings: In Chrome, use Shift + ? with DevTools focus; Firefox uses F1. This is where device emulation, throttling, and experimental settings live.
• Inspect Element Mode: Cmd/Ctrl + Shift + C works across all modern browsers.
• HTML editing: Select an element, then hit F2 (or Fn + F2 on Mac) to toggle inline HTML editing and change attributes or states directly.
• Device mode: Chrome: Cmd/Ctrl + Shift + M; Firefox: Cmd/Ctrl + Opt/Alt + M.

Beyond these, worth knowing are the shortcuts for pausing/resuming scripts and jumping to a matching bracket in the code editor. Full lists are available in the official docs for Chrome and Firefox, and key bindings are largely shared between all browsers.

Turning On Experimental Features

Not all useful features are enabled by default. Hidden in DevTools Experimental Settings, most of these are unstable for broad use and can freeze Chrome — hence the test profile approach. Dedicated profiling profiles can safely switch these on and off per task.

In Chrome, open DevTools Settings (Shift + ? when DevTools is focused), then choose "Experiments." Useful switches relevant to common debugging tasks include:

• Automatically pretty print in the Source Panel: run uncompressed styles and scripts by default.
• CSS Grid and Flexbox debugging: turn on a highlighter that surfaces grid and flex layout edges and gaps.
• Source diff and source order viewer to aid source navigation.
• "Timeline: event initiators" and "Timeline: invalidation tracking" tell you which script precipitated expensive operations like Long Tasks and style recalculations in the Performance panel.

Edge lets you additionally toggle composited layers in its 3D view. For browser-level flags, use chrome://flags/ to enable latest JavaScript, experimental Web Platform features, or resource-loading hints. Firefox exposes its own settings via F1: show browser styles, toggle CSS autocomplete, adjust screenshot behavior, paint flashing, and enable source maps — not on by default there. In Safari, experimental tools are under "Develop → Experimental Settings."

CSS State & Pane Control

In the Elements/Styles panel, applying pseudo-classes like :hover or :focus is a matter of clicking the :hov toggle above the styles list. Chrome offers :active, :focus, :focus-visible, :focus-within, :visited, and most recently :target; Firefox exposes this via a right-click on a DOM node. That same pane has a persistent pain point, though — docks.

For dock position, remember Cmd/Ctrl + Shift + D. It undocks DevTools into a separate window only if it currently sits at the default right-hand docked position; otherwise, it toggles between default and your last chosen position.

Triple Panes in Firefox

Firefox’s Inspector shows a third pane next to HTML and CSS by default — a layout-side view with computed styles, layout tools, and CSS change tracking at all times. It works across sections, e.g., alongside an editable style list with inline media queries and jump targets right next to source. Chrome and Edge get a similar split view only in the Elements panel via the sidebar icon: a Computed Styles side panel, not a full triple pane set.

Property-Level Style Filtering (Firefox)

Firefox DevTools often fly under the radar, yet it packs some powerful features. One such capability is the option to filter all styles by a specific property, activated via the dedicated filter icon. If you suspect certain styles are being overridden by rules scattered across your stylesheets, this filter lets you hide all definitions that don't affect the property in question. This makes it much easier to see exactly where and how the overrides are happening.

Firefox also lets you highlight every element on the page that matches a particular selector. Instead of manually hunting through the DOM or injecting temporary styles, you can find the selector in the Styles panel and click the target icon to "highlight all elements matching this selector." This is particularly handy when diagnosing rendering glitches, such as profile images behaving differently in dark versus light sections of the page.

The Styles panel in Firefox is further enriched with the "Inactive CSS" feature, which explains why certain CSS properties aren't affecting the selected element. Alongside the explanation, it offers recommendations to fix the issue or avoid unexpected behavior.

Additionally, Firefox assigns dedicated badges to identify elements responsible for overflow or scroll issues. This makes it far easier to track down the source of an unexpected horizontal scrollbar or an element that isn't behaving as it should.

Recursive Node Expansion

Traversing a deeply nested DOM can be tedious. Rather than clicking through layer after layer, you can expand an entire subtree at once. Right-click on the arrow next to a node and select "Expand recursively." Alternatively, hold Option (or Ctrl + Alt on Windows) while clicking the arrow icon to achieve the same effect.

Code Coverage Collection and Export

A significant portion of CSS and JavaScript sent to the browser is often unused. The "Code coverage" panel, accessible via the Command menu with "Show coverage," helps identify which styles and scripts are actually executed on a page. This data can be leveraged to gather critical CSS for site templates, a process that would otherwise require tedious manual inspection.

To make this process more efficient, you can simulate various user interactions—such as tapping, tabbing, and resizing the window—and then export the collected coverage data as a JSON file via the export icon in the panel. For more advanced scenarios, Puppeteer offers its own API to collect coverage data programmatically, though Adactio hasn't adopted it yet.

Debugging Media Queries

With numerous media queries in play, tracking down which styles are being overridden and why can get confusing. The media query debugger is designed to help, though it remains hidden by default. To reveal it, toggle the device toolbar via Cmd/Ctrl + Shift + M, click the three dots in the upper-right corner, and select "Show media queries." Horizontal bars will then appear, representing the scope of each media query.

At first glance, the bar alignment may seem confusing. The bars replicate the viewport width on both left and right side of the screen. The classic rule of thumb: bars closer to the center are overwritten by those further away. The colors indicate the type of query: blue bars represent max-width queries, green bars cover both min-width and max-width, and orange bars are for min-width only.

Hovering over a bar reveals which queries it capsulates. Clicking a bar jumps to that specific breakpoint, allowing you to inspect layout issues in detail with the Styles panel open. By right-clicking a bar, you can also reveal its position in the source code. This tool streamlines switching between breakpoints without endlessly resizing the viewport manually.

Beyond standard device presets, you can define custom emulated devices in the toolbar settings. There is also a "Sensors" pane available for controlling device-specific input. In Firefox, you can toggle touch simulation and set a custom User Agent to test how the page responds to elements like search engine crawlers.

Emulating Preference Media Queries

DevTools can also emulate accessibility-oriented media queries, including prefers-color-scheme, prefers-reduced-motion, and various vision deficiencies. Use the Command Menu (Cmd/Ctrl + Shift + P) and type "Show rendering" to access these settings.

The rendering panel also houses tools for "Paint Flashing" and "Layout Shift Regions," which highlight repaint areas and detect layout issues. Additionally, you can preview your print styles here without repeatedly generating PDFs. This makes it trivial to spot and fix print rendering bugs.

Within the same Chrome panel, you can enable further debugging aids like layer borders or disabling AVIF/WebP images. Meanwhile, Safari includes a toolbar option for "Force Dark Appearance" and "Force Print Media styles," while Firefox provides vision deficiency simulation in its Accessibility tab. For print previews in Firefox, a dedicated toggle also appears above the "Styles" pane in Inspect mode.

Auto-Opening DevTools in Every New Tab

When auditing multiple pages at once, managing separate DevTools per window can be cumbersome. You can create a terminal shortcut to launch a browser with --auto-open-devtools-for-tabs, forcing DevTools to open automatically in each new tab. For instance, a simple Alfred script can trigger Chrome Canary with this flag on demand.

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --auto-open-devtools-for-tabs htps://www.smashingmagazine.com

For a full list of Chrome and Edge command-line switches, Peter Beverloo has compiled a comprehensive guide on Chrome Command Line Switches.

Capturing Full-Page Screenshots

When inspecting an HTML node in the "Elements" pane, right-clicking on it grants the option to take a screenshot of that specific node. For broader capture, responsive mode offers screenshot options for the visible viewport or the entire page via the three-dot menu. A faster route is to use the Command Menu (Cmd/Ctrl + Shift + P) and select "Full page screenshot." Bear in mind that lazy-loaded or progressively rendered content, like those using content-visibility, might not appear in the capture unless you pre-scroll the entire page.

In Firefox, the visible portion of the page can be captured by entering "Device Toolbar" mode and clicking the camera icon. For a full-page screenshot, enable "Take a screenshot of the entire page" in the Settings menu first, and then use the camera icon in the main DevTools toolbar.

Measuring Component Dimensions with Rulers

To quickly determine the width and height of a UI element, such as an image or ad placement, all major browsers support ruler overlays. Beyond the standard box-model inspection, Firefox includes a dedicated measurement tool right next to the "Responsive mode" icon. This allows you to draw directly on the page and measure any specific portion of the rendered interface.

Keeping Track of Your CSS Edits

During a debugging session, you may comment out lines or try new rules to solve a problem. When it's time to update the source files, you don't have to meticulously cherry-pick every change from memory.

In Chrome's Sources panel, selecting "Local Modifications" provides a tracker of all edits. If the pane appears collapsed, drag it vertically to expand. This view clearly highlights changed properties and precisely what has been altered, enabling direct copy-pasting of the new rules into your files.

To get accurate diffs, it's crucial to run this workflow against a local server for unminified files, as production builds might strip whitespace and introduce noise into the comparison. Firefox sidesteps this issue with its dedicated "Changes" pane, which logs modifications identically and offers a convenient "Copy All Changes" button for easy migration back to your source code.

Local Overrides (Chrome, Edge)

Iterating on a page without a local build can be painful, but Chrome's Local Overrides are designed for exactly that scenario. Create a folder on your machine to hold the modified files (for example, local-overrides on your Desktop). In DevTools, open the "Sources" tab and select "Overrides" from the top-left corner (it may be behind a double-chevron). Click "Select folder for overrides," pick your folder, and click "Allow" to grant Chrome write permissions.

You can then open any file in the "Sources" panel, right-click anywhere in the code, and choose "Save for overrides". Chrome creates a new file on your hard drive that stores the original contents along with your changes; using the {} button first can make the code more readable. Once active, Chrome intercepts network requests and serves your local code instead of the live response, automatically injecting any changes — much like a dev server with watch mode. Overwritten files get a small purple dot next to them in the "Elements" panel.

The real advantage is that you can open those saved files in your text editor and see changes reflected in DevTools simultaneously, and vice versa — breakpoints set in DevTools are also visible from your editor. Since Local Overrides don't support version tracking, Harry Roberts suggests adding a query string to the URL to load separate variants of the same page, which is handy when editing HTML. To turn everything off, just uncheck "Enable Local Overrides" in the same pane, otherwise those styles will keep overriding the live ones.

Remote Debugging (Chrome, Safari)

Mobile debugging is possible with remote debugging tools. For iOS devices, you can use a DevTools proxy to debug Chrome on iOS or even Mobile Safari from Chrome DevTools. To use Safari's own Inspector, enable "Web Inspector" under "Settings → Safari → Advanced", then open "Develop" and select your phone's name to launch the debugger.

On Android, enable "Enable USB Debugging" in the device's Developer Options, then navigate to chrome://inspect#devices on your dev machine to see your device listed under "Remote Target." Google's remote debugging docs provide full setup instructions, and the same area also hosts dedicated DevTools for Node.js debugging.

Pause Script Execution (Chrome, Edge, Firefox)

To freeze the DOM before a script runs, you can use DOM change breakpoints. Right-click the three dots next to an element's name in the Elements panel and choose "Break on" for subtree modifications (node insertions/removals), attribute modifications (when an attribute or class changes), or node removal.

When you know the code region but only want to pause under certain circumstances, a conditional line-of-code breakpoint can help. Alternatively, use a logpoint to output values to the console without writing console.log statements.

Code Snippets (Chrome, Edge)

Recurring debugging routines belong in the "Snippets" pane of the Sources panel, right next to "Local Overrides." Unlike bookmarklets, snippets are manageable from their own DevTools area and — since they are plain scripts — you can set breakpoints, or highlight just a portion of a snippet to execute only that piece. Run a snippet via right-click or Cmd/Ctrl + Enter, and each snippet is also accessible from the Command Menu.

Many repetitive tasks are good candidates: cache busting, showing headers, saving objects as .json from the console, or modifying the DOM. Community resources like DevTools Snippets provide ready-made scripts, and you can add a performance diagnostics CSS snippet to flag lazy-loaded images, unsized images, or synchronous scripts.

Run Custom Automated Tests (Safari)

Safari DevTools includes the ability to define and run a custom suite of automated checks — if you set up assumptions based on what kind of audit you want. The default suite is centered on accessibility, but you can tailor it to test for sync scripts in the DOM, verify every image has explicit width and height attributes, or confirm that all images are lazy-loaded.

Source Maps (Chrome, Edge, Firefox)

Source maps let you trace minified production code back to the original source modules. In Chrome, enable source maps for JavaScript and CSS in the settings, then add a folder to "Workspace." DevTools will attempt to map everything automatically, letting you set breakpoints and read errors against unminified files. For building them, Webpack's devtool option is a common choice.

Firefox also displays original sources (like .scss or .ts files) in its source list pane — as long as your bundler adds the required comment to each transformed file, pointing to the generated source map.

Clear Service Worker’s Cache And Storage (Chrome, Edge)

A standard "Hard Refresh" bypasses the HTTP cache when fetching assets from the network. But if the page makes dynamic fetches from JavaScript, those can still pull from cache. With DevTools open, right-click the Refresh button to access "Empty Cache and Hard Reload," which clears those too — though neither option touches cookies or service worker storage.

To reset everything, open the Command Menu (Cmd + Shift + P) and run "Clear site data," which wipes service worker cache, cookies, and unregisters the worker. The same action is available in the Application panel. For just cookies or just cache, right-click any request in the Network panel and pick "Clear browser cache" from there. In Firefox, the corresponding option is in the "Privacy & Security" panel under "Cookies and Site Data."

Filters In The Network Panel (Chrome, Edge, Firefox)

The Network panel can display far more than its default columns. Right-click column headers to pick additional ones — the "Priority" column is useful to see how assets are requested and whether adjustments are needed to deliver critical resources faster.

The filter input at the top of the panel isn't just for keywords — it accepts commands. Useful ones include:

• is:from-cache — resources served from cache.
• is:service-worker-initiated — requests triggered by a service worker.
• is:running — incomplete or unresponsive requests.
• larger-than:250k — assets over 250 KiB.
• -larger-than:250k — everything else.
• mixed-content: — assets loaded over HTTP instead of HTTPS.
• -has-response-header:Cache-Control — assets with no caching headers.
• document.write and @import — to hunt down these anti-patterns.

Combine filters with spaces, or type - in the input to see an autocomplete list of all options. The official reference covers the full enumeration, and regular expressions work as well.

Check Initiators In The Network Panel (Chrome, Edge)

Understanding which resource triggered a request — especially when third-party scripts pull in additional scripts — is important when debugging dependencies. In the Network panel, hold Shift and hover over a request. Pink highlights the resources that this element triggered, while green identifies the initiator that actually caused the request to be made.

Emulating a Different User Agent

Checking how a page renders for a specific client, such as Googlebot, is straightforward in Chromium-based DevTools. Open the “Network conditions” panel to adjust caching behavior, network throttling, and the user agent. The default is “automatic,” but ten predefined groups cover common cases from GoogleBot Desktop and Mobile to Android and UC Browser; you can also define a custom user agent. Note that these settings reset when you navigate between tabs.

Firefox takes a different route: you must visit the about:config page and define a general.useragent.override string.

Taming the Performance Panel

The Performance panel's flame charts can overwhelm at first, not least because of unconventional scrolling: by default, vertical scrolling zooms into a selected timeline portion. You can change this in “Settings” by switching “Flamechart mouse wheel action” from “Zoom” to “Scroll.” If you want both behaviors, hold “Shift” while scrolling to toggle between them.

The panel's experimental features, “Timeline: event initiators” and “Timeline: invalidation tracking,” help identify the cause of Long tasks — operations taking over 50ms. The goal is to break these down into shorter tasks, focusing first on the longest ones.

Start profiling with Cmd/Ctrl + Shift + E. Long tasks appear in the timeline highlighted with a red rectangle in the upper-right corner; their length indicates cost. Tasks have a 50ms budget, shown in solid grey, with anything beyond that marked with red/grey stripes. The flame chart breaks each task into its constituent parts, with a yellow background representing scripting.

Click “Evaluate script” under a task to open the “Summary” drawer and see the exact script causing the cost. Clicking a purple “Recalculate style” bar shows what triggered style invalidation — and the Summary drawer lists the affected elements, letting you jump to them directly, as well as the initiating action.

Diagnosing Janky Animations

A few animations, some parallax, or a sliding nav can quickly produce dropped frames. The FPS meter in Chrome's Performance panel shows whether frames are running smoothly; if not, the “Layers” tab helps explore rendering issues. This is where you can spot elements missing a will-change property or using disproportionate memory. For example, we once found a large component hidden off-screen with relative positioning of -1000px, wasting several MB of memory. For canvas debugging, Safari has its own Canvas Memory Usage debugger.

Edge's 3D View for Z-Index Issues

Edge offers an interactive 3D View of the DOM (“Settings” → “More tools” → 3D View) specifically for tracking rendering and z-index problems. You can color the DOM with actual background colors or display only stacking contexts, making it easy to see how z-index values are distributed and why overlays don't appear as expected.

Accessibility Tooling Across Browsers

For a comprehensive accessibility audit, you can combine DevTools with extensions like Accessibility Insights, aXe, and a11y.css, plus other linters and color vision simulators. But the built-in tools cover a lot of ground.

In Chrome and Edge, the “Accessibility” panel displays the accessibility tree, ARIA attributes, and computed properties. The color picker checks contrast ratios against AA/AAA compliance, and you can switch between HEX, RGB, and HSL with Shift + Click on a swatch. The “Rendering” panel can emulate vision deficiencies, and Lighthouse audits include accessibility recommendations. Inspecting an element also surfaces accessibility info in the overview.

Firefox's accessibility tooling is similarly deep, going beyond the tree and contrast checker to highlight roles, landmarks, and provide checks and recommendations. You can test contrast issues page-wide, verify that links are focusable and have focus styling, review text labels, and toggle tabbing order.

Other Features Worth Knowing

• CSS Grid / Flexbox Inspectors (Firefox, Chrome, Edge): Overlays and container boundaries make layout issues visible, with hints covering everything from flex-basis to grid-gap.
• Live Expressions (Chrome, Edge, Firefox): Rather than typing the same expression repeatedly, pin it to the top of the console; the evaluated value updates automatically.
• Animations Panel (Firefox): Track animation issues, slow animations down, and visualize element changes over time.
• Fonts Panel (Firefox): Explore font-related issues, refine typographic properties with sliders, and preview text by hovering over a font-family in styles — useful for matching fallback fonts against web fonts.
• CSS Overview (Chrome, experimental): Adds a tab with a report of CSS declarations, listing colors, fonts, media queries, and unused declarations you can jump straight to.

One last trick: you can debug DevTools with DevTools by hitting Cmd/Ctrl + Shift + I twice in a row.