Chrome DevTools is a set of web-development tools built into Google Chrome. It is not a separate application or hardware device. Developers open it to inspect and temporarily edit HTML and CSS, run and debug JavaScript, examine network requests, profile runtime performance, emulate mobile conditions, and inspect storage, manifests, and service workers.
This guide explains what each major panel does, how to open DevTools, and a practical workflow for diagnosing layout, code, loading, performance, and application-state problems.
What Chrome DevTools is
DevTools exposes the browser’s view of a web page while that page is running. You can see the document structure Chrome built (the DOM), the styles that won or lost in the cascade, messages produced by JavaScript, every network request, runtime activity, and data held by web-platform features.
Most edits made in DevTools are local experiments: refreshing the page normally discards them unless you deliberately use a workflow such as local overrides. That makes DevTools useful for isolating a cause before changing source code, not for silently deploying a fix.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute#1 Best Overall
How to open Chrome DevTools
Use the page context menu
- Open the page in Chrome.
- Right-click the element or area you want to investigate.
- Choose Inspect. DevTools opens with the corresponding node selected in Elements.
Use keyboard shortcuts
On macOS, Command+Option+C opens Elements/Inspect mode and Command+Option+J opens Console. On Windows, Linux, and ChromeOS, use Control+Shift+C for Elements/Inspect mode and Control+Shift+J for Console. Chrome can change shortcuts and menu labels, so check the current Chrome help when a shortcut does not work.
Choose a docking and viewport arrangement
The DevTools menu (the three-dot button in its toolbar) lets you dock the tools to a side or the bottom, open them in a separate window, and select other interface options. If a panel is hidden, open the panel selector (often shown as ») or use the command menu to find it.
The main DevTools panels
| Panel | Start here when you need to | Evidence you can examine |
|---|---|---|
| Elements | Inspect a visible element or its styling | DOM hierarchy, attributes, matched and inherited CSS rules, computed values, box model, layout details, and accessibility information |
| Console | Read messages or run a focused expression | Errors, warnings, logs, stack traces, and JavaScript evaluated in the page context |
| Sources | Debug JavaScript or inspect source files | Breakpoints, call stack, scope variables, source maps, snippets, and local source overrides |
| Network | Find a missing, failed, or slow resource | Request URL, method, status, headers, payload, response, initiator, timing, cookies, and transfer size |
| Performance | Investigate runtime sluggishness | A recorded CPU profile and a timeline of scripting, rendering, painting, and other activity |
| Application | Debug app state or offline behavior | Manifest, service workers, local and session storage, IndexedDB, cookies, cache storage, and related data |
| Device Mode | Simulate a mobile viewport | Alternative viewport dimensions, device presets, orientation, and touch-style interaction |
Panel names and controls can evolve between Chrome releases. The diagnostic purpose of each panel remains the useful organizing principle.
Inspecting HTML, CSS, and accessibility
Select the element you see
Click the Inspect icon (the pointer in a box), then move over the page. Chrome highlights the element under the pointer; click to select it in Elements. You can also use the DOM tree directly and press Ctrl+F (or Command+F on macOS) to search for a selector or text.
Understand which style wins
The Styles pane shows rules matching the selected node. Crossed-out declarations lost to another rule, a later declaration, or an !important rule. The Computed view shows the final value Chrome uses. Expand the box model to see content, padding, border, and margin dimensions.
Click a value to edit it, use the checkboxes to disable declarations, or add a new rule. These changes are ideal for testing questions such as “Is the element hidden by overflow?” or “Which margin causes this shift?” They are not permanent source changes.
Check contrast and related accessibility details
For text and other relevant nodes, Elements can surface accessibility information, including a contrast ratio. Use that result as a lead, then verify the final design across states such as hover, focus, disabled, and dark mode.
Debugging JavaScript with Console and Sources
Console: confirm the symptom
Open Console and reproduce the action. Read the first error and its stack trace rather than starting with every warning. You can evaluate a small expression in the page context, inspect an object, or test a selector:
document.querySelector('#checkout')
localStorage.getItem('cart')
performance.getEntriesByType('resource').lengthBe careful: expressions run with the page’s privileges. Do not paste code you do not understand into a production session.
Sources: stop execution at the cause
- Open Sources and locate the script (source maps can reveal the original source).
- Click a line number to set a breakpoint, or add a conditional breakpoint when the line runs frequently.
- Reproduce the problem. Inspect local and closure variables, the call stack, and the scope chain.
- Step over, into, or out of calls to identify the first incorrect value.
- Remove the breakpoint and retest after changing the real source code.
Snippets are useful for repeatable investigations. Local overrides can serve modified local files, but treat them as a debugging aid and keep the authoritative fix in version control.
Rank #3
Tracing requests in Network
- Open Network before reproducing the problem; recording does not recover requests that happened earlier.
- Reload the page or repeat the action. Filter by
Fetch/XHR,JS,CSS,Img, or a search term. - Open a request and inspect Headers, Payload, Response, Initiator, Timing, and cookies.
A red request often indicates an HTTP error, blocked policy, DNS/TLS failure, or an aborted request; the status and console message distinguish them. A successful status does not prove the response is usable—inspect its body and the code that consumes it. Waterfall timing can show whether time was spent waiting for connection, server response, download, or main-thread processing.
For page-load improvement, start with Lighthouse’s recommendations as a separate audit. Not every load-performance problem is a network problem.
Profiling runtime performance
Use Performance when the page feels slow after it has loaded, interactions stutter, or scrolling drops frames. Start a recording, perform one representative interaction, stop, and inspect the resulting timeline. Look for long scripting tasks, repeated layout or paint work, and the function responsible in the call tree. Record a narrow scenario instead of an entire browsing session; unrelated activity makes the profile harder to interpret.
Emulating devices and conditions
Open Device Mode from the toolbar’s device icon. Select a preset or enter exact width and height, change orientation, and test responsive breakpoints. This is viewport emulation, not proof that every physical phone behaves identically. Verify touch targets, keyboard focus, font loading, and network behavior on real devices before release.
Inspecting storage, service workers, and offline state
The Application panel groups state that is otherwise easy to miss. Review the manifest, service-worker registration and lifecycle, local/session storage, IndexedDB, cookies, and Cache Storage. When an old asset persists, compare the active service-worker version and cache entries with the response seen in Network. Clear only the relevant storage while diagnosing; clearing everything can hide a reproducibility clue.
A practical debugging workflow
- Describe the failure. Record the exact action, expected result, actual result, URL, browser state, and whether it reproduces after a reload.
- Choose evidence by symptom. Use Elements for layout and styles, Console/Sources for code, Network for resources, Performance for runtime work, and Application for storage or offline behavior.
- Change one variable. Disable one CSS declaration, add one breakpoint, or inspect one request so the result is attributable.
- Reproduce and capture. Save the relevant error, request details, profile region, or storage entry.
- Fix the source and verify. Apply the change in the project, rebuild if needed, then retest the original path and nearby cases.
Common problems and fixes
Inspect opens the wrong node
The page may re-render between your click and the inspection. Pause the application with a breakpoint, select the node in the DOM tree, or inspect the stable parent and then move through its children.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Styles appear crossed out
Another selector has higher specificity, appears later, or uses !important. In Styles, expand the winning rule and trace the selector before changing specificity.
No network request appears
Open Network first, enable recording, clear restrictive filters, and reproduce. The data may come from a service worker, cache, or an already completed request; inspect Application and disable cache while DevTools is open when appropriate.
The Console is flooded
Filter by error level or source, clear the console, then reproduce once. Fix the earliest meaningful error; later messages may be consequences.
A breakpoint never pauses
The loaded script may be minified, replaced by a source map, or not the file you edited. Confirm the URL in Network/Sources, set a breakpoint on an event listener or XHR/fetch, and verify that execution reaches the code.
Performance results vary
Close unrelated tabs, repeat the same interaction, keep the recording short, and compare multiple captures. A profile explains one run; it is not a universal benchmark.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Or skip the browser setup
When your goal is a repeatable image or PDF rather than interactive diagnosis, ScreenshotNeo provides a website screenshot API and MCP server. A GET request returns PNG, JPEG, WebP, or PDF. It accepts cookie/consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be disabled. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. AI agents can use its MCP tools—take_screenshot, get_page_info, and capture_pdf.
See the complete parameter reference in the ScreenshotNeo documentation. The following examples use the documented API base and a replaceable URL.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpPython
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)Node.js
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo includes full-page and element capture, 12 device presets plus custom viewports, retina scale, dark mode, PDF controls, custom CSS/JavaScript, click and wait conditions, request blocking, headers/cookies/user agents, timezone and geolocation, transparent backgrounds, resizing, chosen cache TTLs, signed links, asynchronous webhooks, bulk capture of up to 100 URLs per call, usage reporting, and an OpenAPI specification. Every feature is on every plan: 1,000 shots per month free with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.
Free tools Windows power users keep installed
One-click scans. No signup required.
FAQ
Is Chrome DevTools a separate download?
No. It is integrated into Google Chrome and opens alongside the page you are viewing.
Can DevTools permanently change a website?
Normal Elements and Console edits affect your local session. To make a lasting change, edit the project’s source files and deploy them; use overrides only as a controlled local aid.
Which panel should I open for a 404 API response?
Start in Network to inspect the request URL, method, status, response, and initiator, then use Console or Sources if the calling code is constructing the request incorrectly.
Frequently Asked Questions
Does DevTools work on every browser?
This article describes Chrome’s integrated DevTools. Other Chromium-based browsers provide similarly named tools, but their menus, versions, and policies can differ.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesCan I use DevTools to test a page behind authentication?
Yes, while you are authorized and signed in to that page. Network and Application can expose sensitive tokens and stored data, so avoid sharing recordings or screenshots that contain them.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
