My go-to move when something visual’s off is to pop open DevTools and fix it live in the Styles pane. Adjust a value, see the result, adjust again. It’s fast, it’s direct, and I’ve been doing it for long enough that it just feels like second nature.
Then I come across something like a visual shadow editor, specifically designed to make working with shadows easier, sitting two clicks away the entire time 😑
While I’m fighting a losing mental battle trying to make a card pop from the page “naturally,” there’s a small icon in the Styles pane that appears right next to any box-shadow property. Click it, and a full visual editor opens with a draggable handle to:
- position the shadow
- sliders for blur and spread
- a live preview of changes
No refreshing, no saving, no guessing. I’d opened DevTools hundreds of times and walked right past it.
That’s what prompted this post. Not because I was struggling (at least, not a LOT), but because discovering that feature made me realize how much of DevTools most of us aren’t aware of.
We learn what we need to get through a problem and move on. Which means a lot of useful, completely free tools sit there, unused, because nobody told us they were there.
I’ve seen the Accessibility Tree toggle in the Elements panel before. Knew roughly what it was. Never actually clicked into it and explored it until recently, and it completely changed how I think about catching accessibility issues early.
The vision deficiency emulator? Didn’t know it existed until I started researching DevTools.
The Recorder panel? I assumed you needed a separate testing tool for something like that.
But all of it is built into Chrome. No install. No subscription. Just sitting there.
That’s the spirit of this post. It’s an eye-opener for the layer of DevTools most people don’t know about yet.
Whether you’re a developer, a designer doing QA, or someone who wants to understand what’s actually happening under the hood of a page, there’s something here that’ll change how you work.
Related: The Free Browser Tool That Does More Than You Think
Note: If you’re new to Chrome DevTools, open it with F12 (Windows/Linux), Cmd+Option+I (Mac), or right-click any page and choose Inspect. The first shortcut worth memorizing is Ctrl+Shift+P (Windows/Linux) or Cmd+Shift+P (Mac)—this opens the Command Menu, a searchable list of every DevTools feature. We’ll reference it throughout.
Your Browser Is Already a Live Development Environment
Most developers think of Chrome DevTools as a viewer. You look at things, check values, and read errors.
But there’s another way to use it as a live environment where you can make, test, and even save changes.
The Sources panel is where that shift happens, and it has three capabilities that most developers never fully explore.
1. Mocking API Responses Without Touching the Backend
You’re building a UI component that handles an empty state, maybe an inbox with no messages, or a dashboard with no data.
And you run into a problem because the real API always returns data.
You can’t test the empty state without either hacking the backend or hardcoding values into your frontend and remembering to remove them. (Who’s fond of dev URL param flags 😏)
Local Overrides solve this without any of that.
In the Network panel, find the API request you want to mock: Right-click it → Override content.
Tip: The first time you do this, DevTools will ask you to choose a local folder to store the override files. Pick one and click Allow. The JSON response opens directly in the Sources panel editor.
Change it to whatever you need to test:
// Empty state
[]
// Error condition
{ "error": "Something went wrong", "status": 500 }
// Edge case, one result only
[{ "id": 1, "name": "Last Remaining Item", "status": "active" }]Press Ctrl+S to save, reload the page, and your UI renders against your local mock. The real API is untouched. The override persists across reloads until you turn it off.
I used Override content very recently during a demo for a new feature, and it elevated the entire experience I was trying to show. Highly recommend!
You can do the same thing to fix a CORS error on the fly. Right-click a failing request → Override headers → add Access-Control-Allow-Origin with a value of *. Most of the time, this resolves the CORS error without any server configuration or proxy setup.
Note: This works for simple GET and POST requests. PUT, PATCH, DELETE and anything triggering a preflight OPTIONS request may not respond to header overrides, since the preflight carries its own headers that also need to be satisfied. In those cases, a browser extension like CORS Unblock or a local proxy is the more reliable fix.
Local Overrides only affect your browser session. DevTools marks overridden requests with a purple dot, and when you’re done, you can disable them under Sources → Overrides.
2. Workspaces: Edit in DevTools, Save to Disk
You can connect DevTools to your local project folder, and any CSS or JavaScript change you make in the Styles pane or Sources editor gets saved directly to your actual files.
Now, pause, and read that again. ‘Cause I had no idea 🤯
It means you don’t need to copy-paste changes back into your editor.
No “what did I change in DevTools vs. what’s in the file” confusion after a debugging session.
To set it up:
- Open Sources → Workspace (or Settings → Workspace)
- Click Add folder and select your project’s root directory
- Click Allow when Chrome asks for file access
- Reload the page and green dots appear next to mapped files
When green dots appear next to your HTML, CSS, and JS files, the mapping is live. Edit a CSS property in the Styles pane and press Ctrl+S. The change writes to the file on your disk without you touching your editor.
If you’re using a preprocessor like SCSS, be aware that these edits affect the compiled CSS in DevTools, not the original .scss source file.
The mapping can show the change in your CSS output file, but it won’t reach back into your SCSS. So edits there won’t carry over to where you actually write your styles!
Tip 👇
Workspaces work best with locally served projects on localhost and rely on source maps to match browser files to your folder. Frameworks with build steps may need some configuration. Check the Chrome Workspaces docs if you hit issues.
3. Snippets: A Persistent Script Library for Any Page
If you’ve ever typed the same multi-line utility into the Console more than once, like scraping specific data from a DOM or clearing localStorage on a specific key, you need Snippets.
Snippets are reusable scripts stored inside DevTools that you can run on any page, any time, without retyping anything.
To create one: Sources → Snippets (it may be behind the >> arrow in the left sidebar) → New snippet → give it a name → write your code.
Here are a few worth noting:
// Clear all localStorage for this origin
localStorage.clear();
console.log('localStorage cleared');// Log all images on the page with their dimensions
// $$ is the DevTools shorthand for document.querySelectorAll
$$('img').forEach(img => {
console.log(img.src, `${img.naturalWidth}x${img.naturalHeight}`);
});// Find all elements with z-index set explicitly
$$('*').forEach(el => {
const z = getComputedStyle(el).zIndex;
if (z !== 'auto') console.log(el, 'z-index:', z);
});To run a snippet: open it and press Ctrl+Enter (Windows/Linux) or Cmd+Enter (Mac), or click the Run button at the bottom of the editor.
Run a snippet you’ve already saved fast by:
- opening the Command Menu (Ctrl+Shift+P)
- typing
!followed by the snippet name - pressing Enter
All of that without leaving the Console!
Note 👀
DevTools stores Snippets locally in Chrome’s preferences. They survive browser restarts but don’t sync across devices and aren’t accessible as files on your filesystem. If you want to share them with your team, copy the code manually.
Forensic Debugging: Finding Exactly What You’re Looking For
The console.log cycle—add a log, reload, read, add another log, reload again—is so deeply ingrained in how most developers work that it can feel like debugging is that process.
It’s not.
The Sources panel has a full debugger with several breakpoint types that make console.log feel like asking someone to hold a flashlight while you’re trying to do surgery 😬
Logpoints: console.log Without the Cleanup
Before stepping all the way into breakpoints, I’d like to point out a middle ground.
Right-click any line number in the Sources panel → Add logpoint → type what you want to see.
"Cart total: " + cartTotal + " | Items: " + cart.lengthA pink dot appears on that line. Every time execution hits it, that message logs to the Console without pausing or adding a single line to your source code. It survives page reloads for the duration of your session.
To find the right line in Sources:
- If you’re working locally with source maps, your original files appear under the Page tab.
- On a production page or without source maps, you’ll see built or minified files. Click the
{}(pretty-print) button at the bottom of the editor to make minified code readable before setting a logpoint.
This is strictly better than console.log for any debugging work you do in DevTools. There’s no cleanup, accidental commits, or “I thought I removed all those” moments in a code review.
Tip 🤓
Logpoints shine in high-frequency loops where a standard breakpoint would pause hundreds of times. Log the value on every iteration and review the output in one pass without clicking Resume over and over.
Conditional Breakpoints: Pause Only When It Matters
Standard line breakpoints pause every time that line executes. If the line is inside a loop that runs 500 times, you’re clicking Resume 499 times to get to the one iteration you care about 🙈
Don’t do that. Instead: Right-click a line number → Add conditional breakpoint → type a condition.
// Pause only when a specific user is involved
userId === 'abc-123'
// Pause only when the API returns an error
response.status >= 400
// Pause on a specific loop iteration
i === 49
// Pause when a value is unexpectedly undefined
items === undefined || items.length === 0Execution runs normally everywhere else, while the breakpoint fires only when your condition is true. No source changes, no cleanup needed.
XHR/Fetch Breakpoints: Catch the Request Before It Leaves
Your page is making a request to the wrong URL, or a request is firing at the wrong time, and you need to find exactly which line of JavaScript is responsible. Most of us have been through some version of this situation.
You could search the codebase. Or you could set an XHR/Fetch breakpoint and let DevTools find it for you.
In the Sources panel, look for XHR/fetch Breakpoints in the right sidebar. Click the + icon and type a URL string to match on, for example, api/orders or checkout.
The next time any fetch or XHR call is made to a URL containing that string, DevTools pauses execution right on the line that initiated the request.
The call stack tells you exactly what called it and from where.
This is especially useful in SPAs, where data flows through multiple layers (actions, stores, services) and the actual fetch call is several abstractions away from where you started looking.
For example, you’re debugging a Vue app, a cart item gets added, and a request fires to /api/cart/update. You can see the request in the Network panel, but you have no idea whether it’s coming from a Vuex action, a composable, or a direct component call.
Set an XHR breakpoint on api/cart, trigger the action, and DevTools pauses on the exact line that made the call—no grep or guessing.
Explore: The React State Management Guide Nobody Handed You
The Initiator Column: Follow the Chain Backwards
The Initiator column complements XHR breakpoints but lives in the Network panel.
Every request in the Network panel has an Initiator, the thing that caused it.
Hover over any Initiator entry that shows a script and a line number, and a tooltip appears showing the full JavaScript call stack leading up to that request.
Click the link, and it jumps directly to that line in the Sources panel.
This is how you answer “why did this request fire right now?” without adding any breakpoints at all.
You watch the Network panel, spot the unexpected request, hover the Initiator, and the full story is right there.
Network Forensics for Developers
Most developers use the Network panel for two things:
- Checking if a request fired
- Reading the response
But there’s a tier of network tooling beneath that (things like blocking, searching, and profiling) that turns the Network panel into a real diagnostic tool for how your app behaves under pressure or failure 👇
What Happens When a Dependency Fails?
Have you ever checked what your page looks like when a specific third-party script or resource fails to load entirely?
Say your analytics script, font provider, or cookie consent manager didn’t load. What happens to the page if any of these return an error or time out?
Request Blocking in DevTools lets you find out.
Open the Network panel → click the ⋮ (More options) → More tools → Request conditions.
This is the same drawer that handles individual request throttling.
Check Enable blocking and throttling, and add a URL pattern:
analytics.js: blocks your analytics scriptfonts.googleapis.com: blocks Google Fonts.doubleclick.net: blocks an ad network using a wildcard
Now, reload the page with the block active.
- Does your layout collapse without the fonts?
- Does your UI break because the analytics script initializes something your app depends on?
- Is there a fallback, or just silence?
The point is to identify the “unexpected” part. You’re blocking a specific URL you know about, but what you discover is what else breaks because of it.
Block your analytics script, and suddenly, a third feature flag service stops initializing because that script was bootstrapping it.
Block a font provider, and a layout collapses because the CSS was assuming a specific font metric for line-height calculations.
That’s the dependency nobody documented, and blocking it is how you find it.
Search Across Every Loaded File at Once
This one is a keyboard shortcut that doesn’t get enough attention: Ctrl+Shift+F (Windows/Linux) or Cmd+Option+F (Mac).
DevTools needs to be open first, but you don’t need to be on any specific panel. The shortcut works from anywhere inside DevTools and opens a dedicated search drawer across every file the page has loaded—your scripts, third-party scripts, stylesheets, network responses, everything.
Type a class name, a function name, a CSS variable, or an API endpoint string. The results show every file and every line where that string appears, with a preview of each match.
Click any result, and it opens the file at that exact line.
When is this useful? In quite a few situations that come up regularly:
- You see a class name in the DOM and can’t figure out which stylesheet it comes from
- A specific string is appearing in the UI, and you need to find which script generates it
- You’re investigating a third-party script and want to find every place it references a specific endpoint
Tip: The global search panel remembers your search history and supports regular expressions. Toggle regex mode with the
.*button next to the search field.
Building Custom Throttling Profiles
The built-in Slow 3G and Fast 3G presets are useful for general testing, but they’re approximations. Real network conditions can be quite different.
DevTools lets you build custom throttling profiles with exact values:
Network panel → No throttling dropdown → Add… (or navigate to Settings → Throttling → Add custom profile).
You can set:
- Download speed (kbit/s)
- Upload speed (kbit/s)
- Latency (ms round-trip)
A profile that matches the 95th percentile mobile connection in a specific market is much more useful for pre-launch testing than “Slow 3G.”
As a starting point for general mobile testing, something like 1,500 kbit/s download, 750 kbit/s upload, and 150ms latency is a reasonable mid-tier mobile simulation. It’s not the fastest, not the worst, but representative of a large chunk of real users on a busy network.
You build it once, save it by name, and it’s available in the throttling dropdown from then on.
This is where knowing your traffic stats comes in really handy 🙂
The Console Utilities API: The Pro Shortcuts
The Console has a set of built-in utility functions that aren’t part of the JavaScript language and only exist inside DevTools.
Some developers know $0. Most don’t know the rest.
$0 Through $4: Your Last Five Inspected Elements
$0 refers to whatever element is currently selected in the Elements panel.
$1 is the one you selected before that.
$2, $3, $4 go back further, up to five elements deep.
This means you can select two elements in the Elements panel and compare them in the Console without writing a single querySelector:
// Compare the computed width of two elements
$0.getBoundingClientRect().width // Current selection
$1.getBoundingClientRect().width // Previous selection
// Check if an element matches a selector
$0.matches('.active')
// Get all event listeners on the selected element
getEventListeners($0)getEventListeners($0): Find Every Handler on an Element
This one is underused. Type getEventListeners($0) in the Console with any element selected, and you get back an object listing every event listener attached to that element, grouped by event type.
getEventListeners($0)
// Returns something like:
// {
// click: [{ listener: ƒ, useCapture: false, passive: false }],
// mouseenter: [{ listener: ƒ, useCapture: false, passive: true }]
// }Click the ƒ (function reference) in any listener entry, it jumps to the function definition in the Sources panel.
This is how you find “ghost” event listeners, handlers that are still attached to an element after it was supposed to be cleaned up, causing memory leaks or duplicate event firing.
It’s also how you find where an event handler is defined when you can’t easily search for it in the source.
monitorEvents($0): Watch Every Event in Real Time
Select an element, then type in the Console:
monitorEvents($0)Every event that fires on that element (clicks, focus, keydowns, mouseovers) gets logged to the Console as it happens, including the full event object.
This is useful when you’re not sure which event is actually triggering something, or when you need to verify the order in which events fire.
To stop: unmonitorEvents($0).
To watch only a specific group: monitorEvents($0, 'mouse') or monitorEvents($0, 'key').
table(): Turn API Responses Into Readable Grids
If you’re logging an array of objects and trying to make sense of collapsed [Array(50)] output, console.table() renders it as a sortable table. Each key becomes a column header, each item a row.
It’s one of my favorites 😉
// Instead of:
console.log(apiResponse.users) // → [Array(20)]
// Try:
console.table(apiResponse.users)
// → A sortable table with columns: id, name, email, role, createdAtYou can also run it directly on anything in the Console.
Try:
console.table(performance.getEntriesByType('resource'))You’ll see every external resource the page loaded, from images and scripts to fonts, as a sortable table with timing columns.
Tip:
performanceis a built-in browser API, so there’s nothing to set up; it’s available on any page.
The Gemini AI Panel in Chrome DevTools: What It Actually Does Well
When I first saw Gemini show up inside Chrome DevTools, I was curious. An AI assistant that has access to what you’re actually inspecting? That’s interesting.
The first few times I tried it, the responses were decent but not remarkable. Then I started using it more deliberately, and something shifted.
The moment that sold me was a CORS error I couldn’t resolve.
I was making requests to an AWS service and kept getting CORS failures. The origin was added to the configuration (according to the cloud team, it’s their territory), but the error persisted in the Console. I kept copy-pasting it into Google, going in circles between docs and forum threads, trying to piece together what was actually wrong.
Eventually, I hovered over the error in the Console, saw the AI icon, and clicked it. The panel read the error, the response headers, and walked through a few possible causes.
One of them flagged that AWS doesn’t allow wildcards to target multiple origins since each origin has to be specified explicitly. That turned out to be exactly it!
I clicked the “search” button at the bottom of the AI response to continue the conversation in Google’s AI search, asked a follow-up about the wildcard restriction, and got the confirmation I needed.
What makes this different from just asking ChatGPT is that it’s working with the actual error, headers, and context of your session—not a description you abbreviated or pasted. That specificity is what makes it more useful than a cold search for DevTools-specific questions.
How to Open It
Look for the sparkle icon (✨) in the top-right corner of the DevTools toolbar. You can also right-click any console error, network request, or element and select Ask AI or Debug with AI to open it with that item’s context already loaded.
Note 📍
AI assistance requires a signed-in Google account and doesn’t work in Incognito mode. The responses aren’t always perfect, but usually offer a good starting point so you get an answer faster than you would with a cold search. Be aware that your interactions may be sent to Google to improve the feature, so avoid pasting anything sensitive into the prompt!
Five Ways It Actually Helps
1. Explain a Console Error
Hover over any error in the Console and click the AI icon that appears. It reads the message, the stack trace, and the surrounding code, then explains what’s happening and suggests fixes.
It’s extremely efficient for cryptic framework errors where the message alone doesn’t tell you much.
2. Debug a Styling Problem
Select a misbehaving element in Elements, open AI assistance, and describe what you’re seeing: “This element’s margin isn’t applying” or “This flexbox layout is collapsing on mobile.”
It can perform the same investigation you’d do manually, like traverse the DOM, read computed styles, and identify which rule is overriding which, just faster.
3. Investigate a Slow Network Request
Right-click any request that’s taking longer than expected → Ask AI.
It reads the timing breakdown (DNS, TTFB, content download) and response headers, then tells you where the time is actually going and what to look at next.
4. Understand a Third-Party or Minified Script
The next time you try to understand what an analytics snippet or ad network script is executing without reverse-engineering it manually, ask the AI to describe what it actually does.
Trust me on this, it’ll save you lots of time!
5. Get Suggestions From a Performance Profile
Right-click any function in the flame chart → Ask AI.
It reads the recording and identifies what’s taking the longest and why, without you needing to interpret the flame chart notation yourself.
The Application Panel: Storage, Service Workers, and What’s Actually on Disk
The Application panel holds a lot of useful developer tooling for anyone building progressive web apps, managing client-side storage, or debugging offline-first behavior.
It may also be one of the least-explored panels in DevTools 🥲
Storage Forensics: See What’s Living in the Browser
Open the Application panel → Storage (under the Application section in the left sidebar).
You’ll see a pie chart showing how much of the browser’s storage budget is currently used by this origin, broken down by type:
- Cache Storage
- IndexedDB
- Local Storage
- Session Storage
- service worker data
Below that: a Simulate custom storage quota checkbox. Enter a number in megabytes to have Chrome enforce that limit for this origin.
This is how you test what happens when a user’s browser is nearly full. It helps determine whether your caching strategy fails gracefully, or if it throws an uncaught QuotaExceededException in the background.
For example, say you’re building a Progressive Web App (PWA) that aggressively caches assets for offline use. Set the simulated quota to something low, like 5MB, and reload. If your service worker tries to cache a large image bundle and hits the limit, you’ll see the error surface in the Application panel or Console immediately.
Without this simulation, that failure only shows up for real users who’ve filled their browser storage over time. By then, it’s a support ticket, not a test result.
To clear everything at once (all caches, all storage, all service worker registrations ), check the boxes next to what you want to remove and click Clear site data. This is great during development when you need a completely clean slate without hunting through multiple panels. I also find it a quick way to clear the cache without forcing a browser cache clear.
Service Worker Inspection: Debug Background Logic Without Refresh
Service workers are JavaScript that run in the background, separate from the page. They handle offline behavior, push notifications, and caching strategies.
Note 🙂↕️
They’re also uniquely tricky to debug because they have their own lifecycle. A running service worker can keep serving cached content even after you’ve pushed updates, and they don’t respond to normal page refreshes.
Application → Service Workers shows you every service worker registered for the current origin with its status (activating, activated, waiting), the source file it’s running from, and when it last updated.
Three toggles that matter during development:
- Update on reload: Forces the service worker to re-fetch and install on every page load. Use this when your changes to the service worker file aren’t showing up.
- Bypass for network: Tells the browser to ignore the service worker entirely and go straight to the network for every request. Use this when you’re debugging network behavior and need to rule out the service worker intercepting requests.
- Offline: Simulates no network connection. Use this to verify your offline fallback actually works.
You can also click Inspect next to any service worker to open a dedicated DevTools window for that specific worker with its own Console, Sources panel, and Network tab showing only the requests it intercepted.
Service workers are most commonly encountered in two contexts:
- PWAs built for offline support
- Browser extensions, where they handle background processing and message passing between the extension and the page
I worked on a Chrome extension where service workers were managing background data handling with AI and routing messages back to the UI. Without the dedicated inspector, debugging that communication layer would have had me going in blind and cost several hairs.
Tip: If something feels off with background behavior in a PWA or extension, Application → Service Workers is the first place to look. The Bypass for network toggle is especially useful since it makes the browser skip the service worker entirely so you can confirm whether the issue is in the worker or the network.
Five Developer Actions Worth Trying Today
Each of these is a concrete action, not a concept. My advice is to pick one that matches something you’re working on right now.
1. The Clean Reload You Should Be Using
Long-press the reload button in Chrome while DevTools is open. Three options appear. The one most developers never use is Empty Cache and Hard Reload, which clears the entire cache for this origin before reloading.
If you’ve ever spent ten minutes debugging a CSS change that “isn’t applying” and eventually realized you were looking at a cached version, this is the workflow you need.
Make it a reflex at the start of any debugging session where something looks wrong but shouldn’t.
Ctrl+Shift+R / Cmd+Shift+R gives you a Hard Reload (re-fetches resources, ignores cache but doesn’t clear it).
Long-press → Empty Cache goes one step further.
2. The Changes Panel: Track Every Edit You Made in This Session
Open the Command Menu → type “Changes” → Show Changes.
This panel tracks every CSS, HTML, and JavaScript change you’ve made in DevTools since the session started.
Each change is shown as a diff with the original value on the left and your edit on the right.
If you’ve spent 20 minutes tweaking styles in the Styles pane and need to apply all of them back to your source files, the Changes panel gives you the full list.
No need to hunt through the Styles pane trying to remember what you changed and where.
Tip: The Changes panel works with Workspaces too. If you have a workspace connected, you can use it to verify which changes have been saved to disk and which are still only in DevTools.
3. Mock That API Response in Under Two Minutes
Pick any page you’re currently building that depends on an API. Find one request in the Network panel that you want to test against different data.
Right-click it → Override content → follow the prompt to set a local folder if you haven’t already → edit the JSON to an edge case or error state → Ctrl+S → reload.
Your UI now renders against your mock while the real API is completely unaffected.
This one action replaces a mock server setup for most day-to-day frontend development needs, including wasting tokens on generating mock data with AI.
Two minutes to configure, immediately unblocked.
4. Set an XHR Breakpoint on a Request You Can’t Find
If there’s a network request firing on your page and you can’t figure out which line of JavaScript is responsible, set an XHR/Fetch breakpoint.
Sources panel → XHR/fetch Breakpoints → + → type a URL fragment (like api/cart or checkout).
Reload and trigger the flow. DevTools pauses on the exact line that made the call.
Check the call stack on the right side of the panel, and every function that led to this request is listed in order.
Remove the breakpoint when you’re done. No source changes, no cleanup.
5. Open a Snippet and Run It
Go to Sources → Snippets and create a new snippet called audit-images.
Paste this in:
// $$ is the DevTools shorthand for document.querySelectorAll
const images = [...$$('img')];
const missing = images.filter(img => !img.alt || img.alt.trim() === '');
console.table(images.map(img => ({
src: img.src.split('/').pop(),
alt: img.alt || '⚠️ MISSING',
width: img.naturalWidth,
height: img.naturalHeight
})));
if (missing.length) {
console.warn(`${missing.length} image(s) missing alt text`);
}Save it with Ctrl+S, then run it with Ctrl+Enter.
You get a formatted table of every image on the page with the file name, alt text (or a warning if it’s missing), and natural dimensions. Run it on any page, any time, from the Command Menu with !audit-images.
As utilities you build once and reach for across every project, that’s what Snippets are for!
It’s a Wrap
The theme here isn’t really “DevTools has a lot of features.” You already knew that.
The theme is that the features most developers reach for, like console.log, the Styles pane and the Network tab, are sitting right next to a set of tools that do more with less effort.
Tools such as:
- Workspaces so your DevTools edits save to disk
- Snippets so your utility scripts travel with you
- XHR breakpoints so you stop searching and start finding
- Local Overrides so you stop waiting on the backend
- The Application panel so you can actually see what’s happening in storage and service workers, instead of guessing
None of this requires learning everything at once; that’s literally setting yourself up for a burnout.
I’d suggest you pick one thing from the section above that matches something you’re stuck on or doing the slow way. Try it. When it saves you time, come back for another.
There are many features and various other settings in DevTools that a single post can’t cover. And it’s not meant to be—my goal is to remind you that something is sitting in your browser right now that’s free, powerful, and easy to forget.
Take advantage of it!
