How Do You Use DevTools to Diagnose a Broken Website?

What should you record before opening DevTools?

Write the exact URL, browser, device or viewport size, action, expected result, and actual result. Include whether the issue occurs in production, a preview, or both. A report such as “the homepage is broken” cannot distinguish a failed deployment from a layout rule or a single missing image.

Repeat the shortest steps that trigger the failure. Try a second relevant page or a fresh browser session to establish scope, without deleting the user’s browsing data. If the page takes real submissions or changes records, use an approved test environment and synthetic information.

This is more actionable than a screenshot alone because it describes the repeated interaction. A browser’s mobile emulation is helpful, but an actual phone remains important for touch, keyboard, and viewport behavior.

When should you use Elements and Computed styles?

Use the element picker when the issue is visual: an overlapping heading, unexpected margin, cropped image, or hidden button. Inspect the element’s dimensions and its parent containers. A child that overflows may be being constrained by an ancestor’s layout.

In Styles, look for the rule that wins and the rule you expected to win. In Computed, inspect the final value and its source. Temporarily toggle one declaration to test a hypothesis. These browser edits normally affect the current page session; they do not automatically save a correction to your repository.

For example, if changing a fixed card width to a flexible width removes overflow, identify the source file and review why the fixed width existed. Make the durable edit in the source, then retest other pages and sizes. See organizing CSS for avoiding another layer of conflicting overrides.

What does the Network panel tell you?

Open Network before repeating the action, then reload or perform the failing step. Filter by the relevant type, such as images, stylesheets, or Fetch/XHR. Examine the request URL, method, status, response type, and response body where safe.

• 404: the requested resource was not found at that address. Check paths and filename case.
• 200 with unexpected HTML: an asset or API URL may have received a fallback page. A successful status alone does not prove the expected content arrived.
• 4xx or 5xx: inspect the response and endpoint context. The status narrows the investigation but is not the complete explanation.
• No request: the action may not have run, validation may have stopped it, or a different mechanism may be involved.
• A blocked request: inspect the browser’s reason. CORS, content security policy, an extension, or another browser rule can block different stages.

Do not “fix” a blocked request by disabling browser security for customers. Find the intended endpoint and supported configuration. For forms, separate server acceptance from actual delivery using the contact form delivery guide.

How should you interpret Console errors?

Clear old noise, reproduce the failure, and read the first relevant error with its file and line number. A missing script or early exception can cause several later errors. Start with the first failure that plausibly explains the observed behavior rather than fixing every warning indiscriminately.

A stack trace shows where execution passed through code. It does not prove that the displayed line is the only root cause. Check whether a required element was missing, a response shape changed, or code ran before its dependency was ready.

Never paste unfamiliar code into Console to unlock a feature, claim a reward, or follow a stranger’s troubleshooting instructions. Console code runs in the context of the page and can access information available there. Inspect source files and use documented debugging controls instead.

What evidence is safe to share with an AI assistant or developer?

Share the reproduction steps, the relevant source snippet, and a redacted error or request summary. Remove credentials, cookies, authorization headers, personal messages, email addresses, and customer records that are not needed for the diagnosis. Screenshots can expose private tabs and account details too.

A HAR network export may include sensitive request and response information. Even a tool’s sanitized export should be inspected before sharing; do not assume every private value in URLs, payloads, or bodies has been removed. Prefer the smallest evidence that answers the technical question.

How do you distinguish a fix from a temporary workaround?

1. Save the change in the correct source file and inspect the diff.
2. Disable Local overrides, request blocking, offline mode, and throttling if enabled. Reload with ordinary browser settings rather than relying on a temporary Elements-panel edit.
3. Repeat the original steps, including repeated clicks or navigation.
4. Check nearby pages and relevant screen sizes.
5. Verify the expected request status and content, not just the absence of a Console error.
6. Publish through the normal workflow and repeat on the production URL.

If preview and production disagree, use the preview-versus-production guide. If the deployed version is correct but a browser serves old assets, use the cache diagnosis guide. DevTools provides evidence; it does not replace server logs, delivery records, accessibility testing, or the project’s automated checks.

When the browser reports policy violations, use the staged Content Security Policy rollout guide. To prevent a single script failure from blocking core content, review HTML-first progressive enhancement.