How to Use Chrome DevTools to Inspect and Debug Web Pages

To inspect a web page in Chrome, right-click the part that looks wrong and choose Inspect. Chrome DevTools opens the Elements panel at the corresponding DOM node. Use Elements for structure and styles, Console for runtime messages and JavaScript, Sources to pause code with breakpoints, and Network to trace requests and load behavior. Choose the panel that exposes evidence about the symptom, then confirm the cause in another panel before changing application code.

Chrome DevTools is built into Chrome. You can open it by right-clicking and choosing Inspect, or use Ctrl+Shift+C on Windows, Linux, and ChromeOS, and Cmd+Option+C on macOS. For a compact diagnostic map:

Symptom or question	Start in	Evidence to look for
Wrong color, spacing, size, text, or missing element	Elements	DOM node, matched CSS rules, computed styles, box model
Click or form action does nothing; script appears broken	Console, then Sources	Errors, warnings, runtime values, paused call stack
Data, image, script, or stylesheet is missing	Network	Status, headers, payload, response, initiator, timing
Issue occurs only on a small screen	Device Mode and Elements	Responsive viewport behavior, media rules, overflowing nodes
Issue appears after navigation or reload	Network and Console	Requests and messages preserved across reproduction

1. Open DevTools at the point where the problem appears

Right-click the specific visible element and choose Inspect to open Elements with that node selected. For a general page problem, open DevTools first, then switch to the panel needed. The Command Menu (Ctrl+Shift+P on Windows/Linux/ChromeOS, Cmd+Shift+P on macOS) can find panels by name. Shortcuts and panel placement can vary across Chrome releases, so use the menu if a shortcut does not behave as expected. See Chrome’s open DevTools guide.

Keep the page in the state where the bug is visible: signed-in or signed-out, correct route, and any relevant dialog or interaction.
Open DevTools without dismissing the state you need to inspect. If a reload is needed, first enable logging or recording in the relevant panel.
Write down the action that reproduces the issue and what you expected to happen. This makes it easier to tell useful evidence from unrelated warnings.

DevTools can edit a page temporarily. Those edits are useful for checking a hypothesis, but they are not a replacement for changing the source files in your project and reproducing the fix there.

2. Inspect the DOM and CSS in Elements

Use the Select an element tool (the pointer icon) or Ctrl+Shift+C / Cmd+Option+C, then hover and click the page element. The page highlight connects the rendered region to its DOM node. Chrome’s Inspect mode documentation describes the element tooltip, which can show dimensions, colors, font properties, spacing, accessibility name and role, keyboard focusability, and text contrast for headings. Treat these as useful clues, not a complete accessibility audit.

Trace a visual defect

Confirm that the selected node is the element you meant to inspect. Expand nearby parents and children if the visible pixels come from a wrapper, pseudo-element, or overlay.
In Styles, find the rule setting the property in question. Crossed-out declarations lost in the cascade; expand shorthand properties or inspect inherited rules if a value is not obvious.
In Computed, search for the final property value. Expand it to see which rule supplied that value.
Check the box model for content size, padding, border, and margin. Look for a parent with fixed dimensions, overflow clipping, flex/grid constraints, positioning, or a higher stacking context if an element is clipped or covered.
Toggle a declaration or add a temporary rule to test the likely fix. Then make the durable change in your source stylesheet and reload.

// In the Console, inspect the currently selected element ($0 is a DevTools shortcut)
$0
getComputedStyle($0).display
getComputedStyle($0).getPropertyValue('margin-top')
$0.getBoundingClientRect()

Console expressions are read-only unless you call a mutating API or assign a value. For example, changing a style from Console can verify a visual hypothesis but only changes the current page instance:

$0.style.outline = '3px solid magenta';
// Remove the temporary inline style after checking:
$0.style.removeProperty('outline');

If the picker cannot select an invisible, covered, or non-interactive region, use the DOM tree and search for an element by selector or text. Elements may be hidden by display:none, zero dimensions, clipping, or an overlay. An element with pointer-events:none may require holding Shift while hovering in Inspect mode.

3. Read runtime messages and evaluate JavaScript in Console

Open Console directly with Ctrl+Shift+J on Windows/Linux/ChromeOS or Cmd+Option+J on macOS. The Console displays logged messages and acts as a JavaScript REPL for the inspected page. Chrome explains these uses in its Console overview.

Clear or filter old output so the messages from the reproduction are easy to identify.
Reproduce the error and read the first relevant red error, not just the final cascade of failures. A later error may be a consequence of an earlier failed request or exception.
Expand the stack trace and click a source link to inspect the code location. If the file is bundled or minified, use available source maps or pretty-printing to navigate it.
Use short expressions to inspect runtime state. The following examples are safe read operations on the current document:

// Find whether a node exists and inspect basic page state
Boolean(document.querySelector('[data-testid="save"]'))
document.readyState
location.href
[...document.images].filter(image => !image.complete || image.naturalWidth === 0).map(image => image.src)

// Check a specific element's visible geometry and computed style
const item = document.querySelector('.menu-item');
item && {
  rect: item.getBoundingClientRect().toJSON(),
  display: getComputedStyle(item).display,
  visibility: getComputedStyle(item).visibility
}

Use Preserve log when the bug requires a navigation or reload, otherwise the Console can clear as the page changes. Console output may include unrelated browser-extension messages or warnings from third-party scripts. Reproduce in a clean profile or private window if you suspect extensions, while remembering that sign-in state and storage may differ there. Do not paste secrets, access tokens, or personal data into Console commands or public bug reports.

4. Pause execution in Sources when you need to see why code took a path

When a log does not reveal why a handler or state update is wrong, use a breakpoint. The Sources panel lets you view loaded resources and debug JavaScript. Set a breakpoint by clicking a source line number, reproduce the action, then inspect the paused state.

In Sources, open the relevant file. You can also click a Console stack-frame link to jump to a source location.
Click the line number where the value is created or the decision is made. For event-driven bugs, use an event-listener breakpoint or pause at a suspected handler.
Reproduce the problem. When execution pauses, inspect local variables, scope, and the call stack. Hover values or evaluate a small expression in Console while paused.
Use Step over to advance without entering a function, Step into to follow a call, and Step out to return to the caller. Resume when finished.
Compare the actual branch and values with what the code expects. Fix the source in your editor, then reload and reproduce.

For minified bundles, pretty-printing improves readability, but source maps provide a link back to authored files when available. A breakpoint may not hit if the code path did not execute, the source is stale, the browser loaded a different bundle, or the relevant code runs in another frame or worker. DevTools edits to page resources are temporary unless you configure a Workspace; use your normal project editor for lasting changes.

5. Trace missing or failing resources in Network

Open Network before the action or reload you need to investigate; it records requests while DevTools is open. Reload the page or repeat the interaction, then filter the request list by type or text. The official Network reference and network workflow describe the available request details.

Look for the document, script, stylesheet, image, or API request associated with the symptom. Check Status, Type, Initiator, Size, and Time.
Select the request. Inspect Headers for URL, method, status, and response headers; Payload for submitted data; Preview or Response for returned content; Initiator for what triggered it; and Timing for the request lifecycle.
For a failed API call, compare the requested URL and method with the endpoint contract. Verify query/body values, authentication, content type, redirects, and the actual response body. A successful HTTP status does not guarantee the response has the shape your JavaScript expects.
For stale or inconsistent behavior, compare the normal request with a reload while Disable cache is enabled. This setting applies while DevTools is open. Use throttling or offline emulation to reproduce constrained conditions.
To identify which requests block a page, inspect timing and initiators. Consider whether a request is necessary to render the affected part, rather than assuming every slow request delays the whole page.

Useful distinctions: a 404 means the requested resource was not found at that URL; a 401/403 points toward authentication or authorization; a blocked request may involve browser policy, an extension, mixed content, or a blocked resource; a pending request may still be in progress or waiting on a connection or server. Read the response and Console/Issues context before deciding which applies. CORS errors are enforced by the browser: check the preflight and response headers on the server, rather than trying to disable browser security in the client.

6. Check responsive layout with Device Mode

Toggle Device Mode with the device toolbar button in DevTools, choose a preset or enter a viewport size, and reproduce the layout problem. Inspect the affected node in Elements and examine its media queries and computed dimensions. Try the narrow width at which the defect starts, not only one preset. Check horizontal overflow, fixed or sticky positioning, text wrapping, touch-target overlap, and content hidden behind viewport-bound elements.

Device Mode simulates a viewport and selected device conditions; it is a useful first check, not proof of identical behavior on every physical device. Browser version, operating system, fonts, input method, hardware, and network conditions can affect results. Verify important device-specific defects on representative physical devices as well.

7. Use a symptom-to-panel workflow

Problem	First investigation	Then corroborate with
Element is absent	Elements: search DOM; check `display`, `visibility`, dimensions, and parent state	Console for render exceptions; Network for missing data or lazy-loaded assets
Element exists but is styled incorrectly	Elements: Computed value and winning Styles rule	Console for class/state changes; Sources for code changing styles
Button does nothing	Console: reproduce and read exceptions	Sources breakpoint in the handler; Network for the action’s request
API data is wrong or empty	Network: request payload, response, status, initiator	Console for parsing/runtime errors; Sources for state handling
Page differs after reload	Network with Disable cache and preserved request log	Console Preserve log; Application for storage/cookies if relevant
Only narrow layouts break	Device Mode and Elements at the failing width	Network for mobile-only resources; Console for runtime branches

A reliable diagnosis usually follows the evidence chain: visible symptom → relevant DOM or request → responsible rule or code path → reproduction after the fix. Network is for resource activity, not a complete performance diagnosis. For CPU-bound or rendering delays, use the Performance panel; Chrome’s overview links to its performance guidance.

8. Common errors and fixes

What you see	Likely cause	What to check or do
Network list is empty	DevTools opened after the requests already occurred	Keep Network open and reload or reproduce the action.
Console error disappears on navigation	Console log was cleared during page transition	Enable Preserve log, then repeat the navigation.
Inspect highlights the wrong area	A wrapper, overlay, pseudo-element, or nested child owns the visible pixels	Expand nearby DOM nodes; temporarily hide the overlay; inspect ancestors and descendants.
CSS edit appears to do nothing	Another rule wins, selector does not match, or property is overridden by state	Check Computed and Styles for the winning rule, specificity, and active media query.
Breakpoint never pauses	Code path did not run, stale source is open, or execution occurs in another context	Confirm the loaded file in Network/Sources, verify the line is executable, and select the correct frame or worker.
API request fails with a CORS message	Server response or preflight does not allow the requesting origin/method/headers	Inspect OPTIONS and the actual response headers; correct server-side CORS configuration.
Page works with cache disabled only	Cached assets, service worker behavior, or deployment version mismatch may be involved	Compare response headers and loaded asset versions; inspect the Application panel’s service worker and storage state.
Problem cannot be reproduced in Device Mode	The issue depends on physical hardware, OS/browser differences, input, or a viewport threshold not tested	Use the exact failing width and verify on the affected physical device.
Console shows many unrelated warnings	Extensions, third-party scripts, deprecated APIs, or a warning cascade	Start with the first error tied to the reproduction; repeat in a clean profile to isolate extensions.

9. Save useful evidence and make a durable fix

Record the URL, reproduction steps, expected result, actual result, browser version, viewport, and whether the issue survives a reload.
Capture the relevant Console error and request details. Remove credentials, personal data, and private query values before sharing.
For network investigations that need sharing, export a HAR from Network when appropriate; HAR files may contain cookies, authorization headers, or request data, so review and sanitize them first.
Make the change in the project source, then reload and repeat the same steps. A temporary style edit is a hypothesis test, not a verified application fix.
When the issue is intermittent, vary one condition at a time: cache, throttling, viewport, account state, or interaction timing. This helps identify the condition that changes the outcome.

DevTools runs locally in the browser, so basic inspection has no separate tool fee. It adds some overhead while recording, debugging, or profiling, and changing cache or network conditions changes the experiment itself. Keep a record of those conditions so comparisons remain meaningful.

Or skip the browser setup

If the task is to capture a clean page image for a report, visual check, or workflow, ScreenshotNeo returns a screenshot from one API request. See the ScreenshotNeo API documentation for the available options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

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)

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 accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks/CAPTCHAs, blank pages, failed loads, timeouts, and cache hits cost nothing, and response headers report the page verdict and billing status. It also has an MCP server with take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Every feature is on every plan. Create a free account and get 1,000 screenshots a month with no card.

FAQ

Can I inspect a page I do not own?

You can inspect the DOM, styles, scripts, and requests available to your browser on a page you can access. You cannot use DevTools to see server-side source code that was never sent to the browser.

Do DevTools edits change the live website?

Edits normally affect only your current browser page. Make the change in your project and deploy it through your usual workflow for other visitors to receive it.

Why do I see an error but the page still looks fine?

Some errors are non-fatal or belong to optional features. Follow the first error connected to the broken behavior and check whether its request or code path is required for that behavior.

Is Device Mode the same as a real phone?

No. It is useful for viewport and responsive-layout checks, but verify device-dependent behavior on representative hardware.