Browser DevTools Workflow for Debugging Front-End Issues

When a page looks wrong or a button stops working, changing code before you know where the failure occurs can waste time. Browser developer tools let you inspect the rendered page, JavaScript errors, network requests, stored state, and runtime behavior in the same session.

Use them as an evidence-gathering workflow: reproduce the issue, identify the layer that is failing, test one explanation, and verify the smallest fix. The examples below use Chrome DevTools and Firefox Developer Tools. Panel names and details differ between browsers, but the diagnostic questions are the same.

Start with a reproducible case

Before opening panels, write down:

The page or route and the steps that trigger the problem.
What you expected to happen and what actually happened.
The browser and version, viewport size, and whether you were signed in.
Whether the problem happens every time or only with particular data or timing.

Use a test account and synthetic data when possible. A private window can help check whether saved browser state is involved, but it is not a substitute for reproducing the user's exact browser, permissions, and account state.

Choose the panel that matches the symptom. If you are not sure, start with the Console and Network panel, then follow the evidence rather than inspecting every panel at once.

Symptom	Start with
Blank page, missing content, or an uncaught error	Console, then Sources in Chrome or Debugger in Firefox
A form or API-backed view does not update	Network request list, response, then the code that handles it
A layout, color, or breakpoint is wrong	Elements in Chrome or Inspector in Firefox
The issue depends on a refresh or previous visit	Application or Storage panel
A page or interaction feels slow	Performance panel in Chrome or Firefox Profiler
A control is hard to use with a keyboard or screen reader	Keyboard checks and the browser's accessibility tools

1. Capture the Console and Network evidence

Open DevTools before repeating the steps. In Chrome, the Console shows messages and lets you inspect JavaScript in the current page. Firefox's Web Console serves a similar role. Look for the first error that appears during the reproduction, note the file and line if shown, and distinguish your application's messages from unrelated extension or third-party warnings.

For a page-load issue, open the Network panel and reload. For a problem that happens after a click or form submission, keep the panel open and repeat that action. Chrome's Network panel and Firefox's Network Monitor show requests and details such as status, type, initiator, headers, response, and timing.

Use the request list to ask specific questions:

Was a request sent? If not, the event handler may not have run, validation may have stopped the action, or the code may have taken another path.
What response came back? A successful HTTP status does not guarantee that the response contains the data or format the page expects.
Which code started it? Follow the initiator or request details to find the script that made the request.
Where did the time go? Check whether the delay is before the request, in the response, or after the response while the page updates.

Do not treat every failed request as an application bug. A request can be blocked by the browser, fail because of a network or server error, or return an error response that the application does not handle. Check the request details and the matching Console message before deciding what to change.

2. Inspect the rendered page and styles

If the page loads but an element is missing, misplaced, or styled incorrectly, inspect it in Chrome's Elements panel or Firefox's Page Inspector. Select the affected element and check:

Whether the element exists in the DOM at the moment the issue occurs.
Which CSS declarations are active, overridden, or inherited.
The computed dimensions, display, visibility, position, and layout of the element.
Whether a parent element clips, overlays, or hides it.

Temporarily toggling a CSS declaration in DevTools is a useful way to test a hypothesis. If removing display: none makes an element appear, you have narrowed the problem to a style or state decision. Treat that edit as an experiment; make the durable fix in your project source, not only in the inspected page.

For a responsive issue, resize the viewport around the point where the layout breaks and inspect the active media query and computed styles. Chrome Device Mode and Firefox Responsive Design Mode can simulate viewport sizes and some device conditions. Those simulations are approximations, so verify important touch, browser, and hardware behavior on a representative real device. Our guide to responsive web design tools covers additional testing approaches.

3. Pause code at the point where behavior changes

When the Console points to a script but the cause is not obvious, use a breakpoint instead of adding repeated log statements. In Chrome, open Sources; in Firefox, open the JavaScript Debugger. Set a line breakpoint in the suspected handler, reproduce the issue, and inspect the call stack and relevant values when execution pauses.

Choose the breakpoint that fits what you know:

Use a line breakpoint when you know the code to inspect.
Use a conditional breakpoint when the code runs repeatedly but only fails for particular data.
Use an event-listener breakpoint when you need to find which handler responds to a click or input.
Use a DOM-change breakpoint when another script keeps changing or removing an element.
Use an XHR/fetch breakpoint when you know part of the unexpected request URL.

Chrome's breakpoint guide and Firefox's debugger documentation explain these options. If the browser shows bundled or minified code, check whether your build provides source maps so the debugger can map back to the files you edit.

4. Check storage and cached state carefully

If a bug appears only after signing in, revisiting a page, or changing an account, inspect the browser's saved state. Chrome's Application panel and Firefox's Storage Inspector can help you examine cookies, local and session storage, IndexedDB, and cache storage.

Compare the values used by a working and failing test case. For example, check whether the application is reading an old preference, a stale cached response, or a value from a different origin. Change or clear storage only in a local or test session: removing cookies or site data can sign you out or delete information stored by the page.

When you need to test a clean state, use a disposable profile or test account and record what you cleared. Otherwise, you may hide the condition that caused the issue instead of fixing it.

5. Check accessibility and performance when they are part of the failure

For a control that is difficult to operate, first try the page with a keyboard: move through controls with Tab, activate them, and confirm that focus remains visible and follows a sensible order. Chrome's accessibility features and Firefox's Accessibility Inspector can help inspect names, roles, and the accessibility tree. Automated findings are useful, but they do not prove that a page works with a keyboard or screen reader. See our guide to testing website accessibility for a broader review.

If the issue is slowness, capture a short trace around one page load or interaction. Chrome's Performance panel records a profile you can inspect for long-running work and rendering activity; Mozilla documents the Firefox Performance Tool. Start with a specific slow action instead of recording a long session, then investigate the part of the trace that matches the delay.

A local profile depends on the computer, browser, cache, and network you used. Throttling and emulation help compare conditions, but they are not exact measurements of every user's experience. For more on measurement and optimization, see our guide to web performance optimization.

6. Make one fix and repeat the same test

Once the evidence points to a cause, state the explanation before changing code. For example: “The request succeeds, but the page reads the response's items field while this endpoint returns results.” Then make one focused change and repeat the same steps with the same browser, viewport, and test data.

Confirm that:

The original symptom is gone.
The Console and relevant requests show the expected behavior.
Nearby states still work, such as an empty result or a failed request.
The fix behaves acceptably in the other browsers and viewport sizes you support.
A regression test covers the failure where practical.

If you share a screenshot, trace, or exported network log with a teammate, review it first. Requests and storage can include account identifiers, private responses, cookies, or authorization headers. Redact sensitive values and share only the evidence needed to reproduce the bug.

A short debugging checklist

Can you reproduce the issue with clear steps?
Did you capture the Console and Network activity during the reproduction?
Did you check the actual response and rendered DOM, not just the visible symptom?
Can you identify the first code path or state value that differs from expectations?
Did you test the fix with the same steps and check adjacent cases?
Did you verify the browsers, devices, and accessibility requirements that matter to your users?

Browser DevTools are most useful when you use them to test a specific explanation. Start with the failing behavior, gather evidence from the relevant panel, and keep changing one thing at a time until the same reproduction passes.