Contents (Click to expand) ↕️
Enabling design mode will make the entire web page editable, just by clicking and typing.
To use it, open up the console and run:
document.designMode = 'on'
Raw files are usually minified, and therefore hard to read. Use the Pretty Print option to format it
In the background, Chrome is creating a new file (names
filename.js:formatted), closing that file will undo the formatting.
If doing this each time is getting boring, then there's an experimental setting to auto-enable pretty print for all sources.
Automatically pretty print in the Sources Panel.
The command pellet gives you full access to every command available within the dev tools, and is super valuable for quick navigation.
Type Ctrl + Shift + P to open up the Command Menu, then start typing to filter commands and press enter to execute.
In the same way, if you're only looking to find a function name, you can use Ctrl + Shift + O to filter methods across files.
From the same menu, you can also search through all loaded resources by filename or code (HTML, CSS, JS, etc), all network requests, visible components, memory profiles, snippets and much more. Advanced features like RegEx are supported.
For an app built with a framework, you'll probably see a lot of irrelevant files (like node_modules, webpack output, etc). You can hide this under ⋮ → Hide ignore-list sources. By default, this uses the smart
x_google_ignorelist to detect what's likely not relevant, but you can also add your own custom sources, specified by regex under Settings.
So you've spent a while crafting a function in the console, and you plan on reusing it across various sites later. That's where snippets come in, they're invoked from the command pallet, and let you save code for later and execute it using the bang
Instead of repeatedly executing a command to monitor for changes, you can watch values in real-time using Live Expressions. Just execute a command, then pin it using the eye icon to see changes reflected automatically.
There's many use cases for this, but one I use often is when testing keyboard navigation of an app, pinning the
document.activeElement command will print a log of evertime the focused element changes, even once it's been removed from the GUI.
We've all been there, you've been editing your app's HTML, CSS and JS through the dev tools and got things working perfectly, but you can't remember exactly what you changed. That's where the Changes Tab comes in. Access it through the command pallet (with Control+Shift+P, then type "Show Changes"), or through the lower draw.
You'll then be able to see a diff output of all your changes. From here you can Copy changes to clipboard, or revert certain changes.
$()- Short-hand for
Document.querySelector()(to select DOM elements, jQuery-style!)
$$()- Same as above, but for
selectAllfor when returning multiple elements in an array
$_- Returns value of last evaluated expression
$0- Returns the most recently selected DOM element (in the inspector)
$4can also be used to grab previously selected UI elements
$x()- Lets you select DOM elements using an Xpath query
values()- Shorthand for Object.getKeys(), will return an array of either obj keys or values
copy()- Copies stuff to the clipboard
monitorEvents()- Run command each time a given event is fireed
- For certain common console commands (like
console.table()), you don't need to type the preceding
console., just run
You can clear the console at anytime using Ctrl + L, using the clear button, or by running
There's many more console shorthand commands, here's a full list.
Warning These tricks only work within the dev tools console, and will not work in your code!
Easily identify which bundles are the largest, and how much of their code is actually used, and what the load impact of each file is, using the Coverage tool. This illustrates exactly which code is being loaded but never used, and what the cost of it is.
Click the three dots, select coverage and reload the page. Any red bars indicate unused code, and will likely be making your app slower. Clicking an individual file will let you see specifically what code isn't being used.
This tool is super useful for identifying elements that are being edited more often than possibly necessary, and which are likely negatively affecting performance and user experience.
The frame rendering stats is specifically useful, for monitoring CPU and GPU usage, helping you identify things before they become a problem.
Your probably familiar with the waterfall chart rendered by the Network tab, and how useful that is for detecting slower requests. But from here, you can also enable screenshots to see exactly what parts of your site will load visually for end users on slower connections.
Clicking on an item shows headers and response, but head to the Timing tab, and you'll be able to see what stage the request was held up at, and specific server timings. Using the Server-Timing API, you can pass even more detailed info from your API to your client app, and view data in the Timings tab of the browser dev tools. To use this, just add the
Server-Timing header to your response data, and detailed charts will be visible in the dev tools.
To find the total size of your web page, under the Network panel, check Disable Cache, reload the page, and the info bar at the bottom will display total size, total time, total requests and other key stats.
You likely already know this, but you can also view the request and response for any HTTP request your site makes, as well as view loading times and see where in the code it was triggered.
It's really worth exploring the performance panel and all that it has to offer. Just hit the record button, then interact with your site like an end-user might. When you're finished, you'll have a really detailed breakdown of CPU usage, FPS and memory allocated to the heap. Where ever there's a spike in the timeline, that usually indicates an area of code that needs to be optimised. You can then investigate this further by drilling down on the flame chart, to see the full stack trace of everything that happened on the main thread.
Modern browser automatically garbage-collect any data that is no longer being referenced to. But poorly written code can mean you have obsolete code references that build up over time causing a memory leak. This can be detrimental to performance and greatly hider user experience.
Thankfully, they're not as hard to find or debug as you might have thought. Under the Memory tab, select "Allocation instrumentation on timeline", then hit record.
The blue bars indicate memory that's still in use, and the grey bars show what was garbage collected. So a rapidly growing blue bar would be where your mem leak is happening, and you can then click that bar to see exactly what data objects they contain, and easily identify the cause.
Worth also noting that the web page isn't the only source of memory leaks. They can also be caused by add-ons, the browser engine itself or even data caching. Use the Statistics view to see a breakdown of what data is using memory.
If you're building a web assembly app, this will be particularly important to you. From the memory inspector, you can drill down the scope, and inspect ArrayBuffer, TypedArray, DataView, and Wasm Memory. Here's a WASM demo:
bfcache is a browser feature that enables instant backward and forward navigation, it works differently from the HTTP cache because it stores a snapshot of the entire page in memory, which is what the user will see while the navigation is happening.
In order for the bfcache feature to work effectively on your site, you need to optimise for it. And that's where the Back/Forward Cache Tester comes in. Under Application → Back/forward cache tab, click "Test back/forward cache", and you'll be presented with the results which will list issues for each frame. Clicking each result will also give you instructions on how you can fix it.
Some errors are caused by cached content, and for those a normal refresh isn't enough. With the dev tools open, you can hold down the refresh button (for 2 seconds), and you'll see some additional refresh options, including "Empty Cache and Full Reload".
This is also useful for measuring first-time load metrics for new users, when nothing is previously cached.
To refresh all tabs at once, just reun
chrome://restart in the address bar.
Lighthouse is an extremely useful (and easy!) tool for measuring Core Web Vitals - accessibility, SEO, responsivness, performances, security, PWA compatibility, best practices and overall user experience.
Just open the Lighthouse tab, and click "Start Scan".
Lighthouse results can be exported in a range of formats, and there are various external viewers you can use to gain additional insight (like this one).
Lighthouse scans can also be incorporated into your CI/CD system, so that you have constant visibility into your apps core vitals.
Understanding what data is being loaded into your site will help you reduce overall bundle size. This can be done from the Memory and Network tabs, but sometimes a more visual view helps put things into context.
The Chrome Memory Treemap is really useful for this - to use, just run a Lighthouse scan, export the results in JSON, then import it into googlechrome.github.io/lighthouse/treemap/.
You can click any element, to zoom in and inspect additional info.
Note (This feature is still in beta, and currently requires Chrome Dev Eddition)
Record, reply and audit user flows under the audit panel. Just click Start new Recording, enter a name and hit go. Everything the user does, including mouse moves, keypresses, pauses and more will be logged. You can then use Replay to view back the users journey.
In the replay settings each step can be expended to view details, you can also edit, add and remove steps in real-time. There are additional options for simulating things like environment of slow network connection. This is super useful for user testing.
You can also import and export user flows as a Pupateer scripts, to share with others.
The recorder tool has many other valuable features which often go under-used. Being aware of what you can do, will help you supercharge your user testing.
Examples of when this can be useful include: sending the exact steps to recreate a bug to another developer, demonstrating to an analyst exactly how users behaved during a testing session, or slowing things down to debug complex issues.
Once you've recorded a user flow, you can:
- Replay it (obviously!)
- View detailed performance metrics over time
- Export it (as JSON, Puppeteer or Puppeteer reply script)
- Edit the flow (then re-import it)
- Share user flows with others (for testing or demonstration)
- Configure replay settings, such as apply throttling or device limitations
- Replay in slow mo, with detailed debugging
- Apply breakpoints, to pause and inspect at certain steps
- Import user flows generated by other tools
- Add additional steps, or remove steps
Breakpoints are an absolute essential for debugging. They enable you to pause everything at a certain point to inspect state and discover issues. You're probably already aware that you can trigger a breakpoint at a certain point, either with the
debugger statement statement, or by clicking the margin (in the sources panel, or with a compatible IDE). But there's several other types of breakpoints, including:
- Conditional line-of-code - On an exact region of code, but only when some other condition is true.
- DOM - On the code that changes or removes a specific DOM node, or its children.
- XHR - When an XHR URL contains a string pattern.
- Event listener - On the code that runs after an event, such as click, is fired.
- Exception - On the line of code that is throwing a caught or uncaught exception.
- Function - Whenever a specific function is called.
If there's a specific method you want to pause on, just run
debug(methodName) to start, and
undebug(methodName) to end.
Once a breakpoint has been hit, you can interact with any current state through the console.
As any app developer will tell you, nothing beats testing on a real device. But when it comes to the web, the browser debugging tools are essential. That's where remote debugging comes in - it enables you to test on a physical device while continuing to have the debugging power of the browser tools.
The same can work in the opposite direction, where you run your dev environment locally or host it remotely, but access it on an external device.
This does require either port forwarding or custom domain mapping (but neither are as scary as they sound!). The docs provide setup instructions and proxy configurations.
And if you're developing a native Android app, which has embedded web views, you can use the browser's dev tools to debug these too (docs).
In a similar way to the iOS and Android emulators, you can simulate various sensors and hardware settings. This is useful if the app your developing relies on any of this data. Under the Sensors tab, you'll be able to change your location, time zone, locale, screen lock, orientation, motion / acceleration etc.
If you frequently find yourself switching between locations or locales, you can add these under Settings --> Locations.
If you're wading through a large code base or dealing with a poorly written library, and drowning in exceptions which are distracting you from what you're actually trying to debug, then under the settings you can opt to ignore any exceptions thrown by certain scripts or from a given framework. The ignore list can be specified by regex patterns for specific targeting.
You can auto-hide source files for most major frameworks by heading to ⋮ → Ignore List, and selecting "Automatically add known third-party sources to Ignore list". This will make the stack trace in the console show less irrelevant info. You'll still be able to view the full stack for any given error, just by clicking "Show more".
By default the console will show output from all contexts. This means if you've got an extension installed that's throwing an error it will be cluttering up your console. Just right-click on the file name, and under Filter select Hide messages from [ext name]. You can unhide these at anytime from the same menu.
While we're in the Application tab, it's worth mentioning how essential these tools are for viewing, deleting and editing data stored in local storage, session storage, cookies, IndexedDB, etc.
From the storage tab, you can also see a breakdown of how much your site is storing, and simulate restraints like custom storage quotas or disabling cookies.
Note that stored data is (usually) only accessible from the domain which set that data. So if you're debugging stored data in the console for any context other than the default one, you'll need to use the frame dropdown at the top to switch domains.
If you app includes notifications, sync, background fetch or anything else that should continue running even when the app / current tab is not in the foreground, then these tools are invaluable. Under the Application tab's Background Services section, you can click a API category, start recording, then put your app into the background. When you come back, you'll be able to see specifically which events fired, and inspect each one.
Side note, you can view all registered service workers, manage, debug and de-register them from:
The Security tab provides a good starting point, for when verifying common HTTPS issues on your site. It checks for, and highlights common SSL issues, including non-secure main origins and mixed content. You can also check web certificate chains in more detail.
This ones a bit more niche, but absolutely essential if you're building anything with soft-tokens or 2FA. The WebAuthn tool will let you generate and emulate virtual authenticator devices using a variety of protocols (2FA, FIDO/CTAP) and interface types (USB, NFC, Bluetooth, internal) with additional options for user verification, resident keys, etc.
Here's a quick demo:
On a side-note, there's an interesting article explaining how they built the webauthn tab.
Accessibility is not just important for inclusion, it's also a legal requirement for most public-facing apps and services. If you're not yet sure the core concepts of web accessibility standards, I recommend the Web.Dev Accessibility Tutorial, which provides a great summary.
Lighthouse provides a good starting point for auditing accessibility, and is easy to use, and built directly into the developer tools.
The CSS tools also have a built-in contrast tool, which will help you apply readable colors to your site. The inspect pop-up will show a warning, and you can analyze this further in the Styles pain.
Beyond that, the Accessibility tab let's you view an element's position in the DOM tree, ARIA attributes, and computed accessibility properties, all of which are used by accessibility tools like screen readers.
There are additional add-ons which can give you much more powerful insights. Mainly, the axe DevTools. This will show you detailed results and instructions of how to fix.
You can capture screenshots directly from the dev tools, including: full-page, specific area or single-node screenshots.
Either open up the command pallet and type screenshot, or for an element screenshot, just right-click on the DOM element in the inspector and select Capture Screenshot.
The animations panel (opened by clicking the 3-dots) lets you record any keyframe animations, and then scrub through them to inspect the actual CSS properties that are affected.
If you need to preview the styles of a given element in a particular state (e.g. :hover, :visited, :active, :focus, etc), then either right click it and select Change pseudo class, of from the the styles editor click the :hov icon.
Do you ever inspect an element, then hold the arrow keys up/ down for literally ever until the size looks right? Well you can also drag the units horizontally to easily preview different sizes. Similarly, for angles you can use the clock rotater to preview / apply any value. Got the wrong units? Just hover over the size, and click the drop down to quickly switch units.
Most apps include only a handful of colors, and usually when your changing a color, it will be to one of those values. That's why the palette tool is so useful. By default, there are several pre-made palettes: from your pages current colors, your pages CSS variabels, the Material pelette and an empty custom palette. Switch between them with the arrows.
While we're here, it's worth also touching on just how powerful the color tool is. From here you can:
- Change color shades, hue and transparency - with live preview
- Convert between units (hex, RGB(A), HSL(A), HWB(A))
- Use the eye dropper to pick any color from your screen
- Copy color value to the clipboard
If you're not already doing so, try to make use of CSS variables (not SASS vars) throughout your app. That way you can update the color in one place, and have it previewed/ applied everywhere. In the dev tools, click a variables name to go to original definition, from there you can modify it.
Box shadows are one of those things that are best previewed live. That's why the shadow-editor is so useful. Just click the icon next to any shadow to preview different X/Y offsets, blur, spread and directions of both inset and normal shadows.
By clicking the animation option, you can easily preview various transitions and effects.
Easily check that your site displays nicely on a range of devices, using the Responsive Design Mode.
By default only a few devices are shown, but head to Settings --> Devices and you'll be able to enable a whole bunch more from the list, or even create your own custom device with dimensions, user agent, platform, architecture and more.
You may have notices a little chip/ badge next to certain elements in the Elements tab. These are Badges, and can be used to apply overlays or add extra features to certain element types including Grids, Flex layouts, Ads, Scroll-Snaps, Containers, Slots and more. To enable badges, right-click an element in the DOM tree and select Badge settings, then check / uncheck what you'd like to be visible.
There's always that one front-end dev, so keen to please the designers that he's using an actual ruler to measure the elements on his screen. Well no need for that, or any dodgy ruler browser extensions, as this feature is built directly into the dev tools. Enable it under ⋮ → Settings → Preferences → Elements → "Show rulers on hover".
In Firefox, there is a built-in ruler feature, available through the Toolbox Buttons in the top-right.
The CSS Overview tab helps you quickly get an overview of CSS improvments you can make. The aim is consistency (colors, fonts, breakpoints, styles, etc).
- Color Pallet - Shows all colors used on your site. Useful for identifying elements which don't conform to your desired theme / designs
- Fonts - Displays all typefaces, sizes and variations used in your page. A good webpage will be consistent with only a few fonts and text styles.
- Media queries - Outputs all breakpoints used in your site, sorted by highest occurrence. You should aim to keep them consistent to make responsive testing easier
- Unused Declarations - Lists key information about any unused declarations as well as styles that have no effect. Removing these will speed up load times, and make CSS easier to read.
The Layers panel (more tools → Layers) will show what's happening both off screen and on additional layers (with 3d mode).
It's particularly useful for visualising how specific animations are working, from a functional perspective, without having to wade through a bunch of keyframes and obfuscated code.
There are two methods to save or persist changes you've made in the dev tools. Workspaces and Local Overrides.
Workspaces enable you to save changes you make in the devtools directly to your working copy on disk
Local Overrides enable you to persist changes across sessions (but without effecting original source files)
Overrides can be setup under Sources → Overrides. You can use the Changes menu to preview / export a diff of what you've changed.
For more advanced tasks, everything in the developer tools can be automated, via the Automation APIs using WebDriver Protocol (which is what tools like Selenium use). As an example, see the webdriver devtools package.
So almost everything within the browser developer tools has keyboard shortcuts, here's the full list. But if you're struggling to memorise them all, then you can actually switch to familiar VS Code bindings. Under Settings --> Shortcuts, under the Match shortcuts from preset menu, select Visual Studio Code.
Finally, but by far the most important tip of all: dev tools dark mode!
Under Settings --> Preferences --> Appearances --> Theme, use the dropdown to switch from Light to Dark, and immediately 10x your developer experience. Because like they say... bugs are attracted to the light 🐛🔦
And if you're too cool for the default dark mode, you can write your own stylesheet, then enable the custom loading of CSS! There's a few pre-made stylesheets and an extension available here.
We're not quite done... so far we've only covered the built-in dev tools, but there are a bunch of super useful add-ons/ extensions
If you're working with a specific framework (like React, Svelte, Vue, etc), then adding their dev tools with give you additional debugging power over components, state and more.
- React Dev Tools - Inspect React component hierarchies and profile data
- Redux Dev Tools - Debug redux data and monitor state changes
- GraphQL Network Inspector - Inspect GQL requests with support for relay batching
- Vue Dev Tools - Debug component hierarchy and state in Vue apps
- Svelte Dev Tools - Inspect the Svelte state and component hierarchies
- Angular Dev Tools - Preview state of directives of Angular component instances
- Meteor Dev Tools - Debug Meteor apps
Beyond that, almost everything else can be done nativity / without additional extensions, there's still a few QoL add-ons that can be helpful, but keep in mind, that if you use any of these, you should create a separate Dev profile within your browser, as otherwise they may negatively effect you privacy (installed extensions make you more identifiable).
- Visbug - Interact with and modify any websites, without needing any HTML or CSS knowledge
- Lighthouse - Automated performance, quality and correctness checker
- Designer Tools - Grids and rulers for in-browser measurement and alignment
- Motion Tools - Inspect and design complex CSS animations
- Pixel Perfect - Overlay designs over webpages for building pixel perfect pages
- CPU + Mem Performance Monitor - Add system resources overlay to sites
- SEO Inspector - Easy inspection of Meta tags for SEO
- Save all Resources - Easily download everything associated with a site, preserving directory structure
- Multi-Proxy - Connect to multiple proxies (simultaneously) with IP matching and blocking
- Accessibility Insights - Get an overview of accessibile navigation issues
- Check my Links - Quickly find and highlight all dead links within a page
- Weppalizer - Similar to BuiltWith, quickly check what tech a site is built using
- Octotree - Adds sidebar on GitHub for much easier navigation
Alright, this time I swear it's the last section, but I couldn't resist mentioning this too!
There is SO MUCH more to the browser developer tools than covered here. Even if you've been a web developer for several decades, I'm pretty sure there's still a whole bunch of handy features that even you've not yet come across. So don't be afraid to go exploring!
The best features are still experimental. You can try them out by enabling them under Settings --> Experiments. There's a link next to each item where you can view a usage tutorial as well as the API docs.
- Firefox dev tools has a very similar feature set and layout to Chrome, but includes a few advanced features (around audio, shaders)
- Safari's developer tools are lagging behind in terms of features, but are sometimes still required for iOS testing.
- Other Chromium-based browsers (like Edge, Brave, Vivaldi, etc) inherit from the same source as Chrome, and as such have virtually identical dev tools.
The following sources are great for staying up-to-date with the latest in debug tools: