A page looks fine on your laptop, then someone reports that the menu does not open, the form spins forever or the layout is broken on a phone. The first instinct is often to change a CSS rule, refresh the page and hope. That can work, but it also turns a small bug into a trail of guesses.
The browser already has useful evidence. Its developer tools can show the element that is being styled, the JavaScript error that stopped a click handler, the request that returned an error and the work that made the page slow. The trick is to inspect those clues in an order that narrows the problem instead of creating more noise.
Quick Answer
Open DevTools and reproduce one problem at a time. Start with the Console for errors, use Elements to inspect the actual HTML and CSS, check Network for failed or delayed requests, and use Performance when the page is slow or janky. Record what you observed before editing anything.
Do not treat a red message as an automatic diagnosis. A warning may be unrelated, a request may fail because of an intentional cancellation, and a CSS change made in DevTools disappears when you reload. DevTools is an investigation surface, not a replacement for a fix in your source code.
1. Reproduce the exact complaint
Write down the page, action and expected result. “The website is broken” is too broad to test. “On the checkout page, clicking Pay after entering a valid address leaves the button disabled” is a useful starting point.
Also note the browser, device, account state and whether the problem occurs every time. A logged-in path may load data that a guest path does not. A bug that appears only after a second navigation may point towards stale state or a client-side route rather than a missing CSS declaration.
Open a private window or a clean browser profile when extensions or cached data might be involved. This is not proof that the problem is solved, but it gives you a comparison. Avoid changing five variables before you have a baseline.
2. Start with the Console
In Chrome, open DevTools with the keyboard shortcut for your operating system or right-click the page and choose Inspect. Select Console, clear old messages, then perform the failing action again.
Look for the first error that appears at the moment of failure. An exception such as Cannot read properties of undefined may be the cause; several later errors may simply be consequences of the first one. Follow the linked source file and line number. If source maps are available, the browser may take you to the original source instead of a bundled file.
Do not paste a random fix into the Console and call the issue closed. A Console experiment can tell you whether a selector exists or whether a value has the shape you expect, but the durable change belongs in the project source, followed by a test.
The Console is also useful for checking assumptions. You can inspect whether a button is disabled, whether an element has a class, or whether a global configuration value exists. Keep those checks small and avoid running code that changes customer data or sends real requests.
3. Inspect what the browser actually received
The Elements panel shows the live DOM, not necessarily the HTML you remember writing. Frameworks can add wrappers, replace nodes or render a different branch after an API response. Select the visible element and ask three questions:
- Is the element present and in the expected parent?
- Is the text or attribute value correct?
- Is another element covering it or preventing interaction?
The Styles pane shows which rules apply and which declarations are crossed out. A crossed-out display: flex may have lost to a more specific selector or a later rule. The Computed view helps you see the final value after inheritance and the cascade have done their work.
You can temporarily edit a value to test a theory. For example, changing overflow: hidden to overflow: visible can reveal whether a menu is being clipped. If that makes the problem disappear, record the observation and then fix the selector, layout or component that owns the rule. Do not leave the browser edit as the solution.
For a mobile layout, use Device Mode as a test aid, then verify on a real phone where possible. A simulated viewport can reveal a breakpoint problem, but it cannot reproduce every touch, font, memory or browser-UI condition.
4. Read the Network panel like a timeline
When content is missing, a form does nothing or a page waits indefinitely, open Network, clear the list and reproduce the action. Chrome records requests while DevTools is open. Filter by Fetch/XHR for API calls, or search for a filename, endpoint or status code.
For the request that matters, check:
- the request URL and method;
- the status code and timing;
- the request payload and important headers;
- the response body;
- whether the browser reports a CORS, certificate or mixed-content problem.
A 404 usually points to a wrong path or missing deployment asset. A 401 or 403 suggests authentication or authorisation. A 500 means the server failed, although the frontend still needs to present that failure clearly. A request that never appears may mean the click handler stopped in JavaScript or the browser blocked the action before sending it.
Do not expose real tokens or private request bodies when sharing a screenshot or exported trace. Redact cookies, authorisation headers, customer details and reset links. A debugging artefact can become a data leak if it is treated as harmless.
5. Separate slow from broken
A slow page and a failed page can look similar to a user. The Network waterfall helps you see whether the delay comes from the server, download size, connection setup or a request that is waiting behind another dependency.
For runtime sluggishness, use the Performance panel and record a short, repeatable interaction such as opening a menu, filtering a table or scrolling. Look for long tasks, repeated layout work and expensive scripting. Slow JavaScript may make a button feel broken even though the request itself is fast.
Chrome also lets you simulate slower network and CPU conditions. This is useful for finding a page that only works comfortably on a powerful development machine. Treat the simulation as evidence for a test scenario, not as a prediction of every user’s device.
6. Use breakpoints when the error is not obvious
If a click reaches JavaScript but the result is wrong, set a breakpoint in the handler or use an event listener breakpoint. Step through the code and inspect values at the point where the assumption stops being true.
For example, the UI may expect response.items while the server returns an object with data.items. The error is not “the list component is bad”; it is a contract mismatch. Once you can state the mismatch precisely, the fix might belong in the API, adapter or component test.
Common mistakes to avoid
The most common mistake is changing code before capturing the symptom. You lose the original state and may end up debugging your attempted fix. Another is treating every console warning as urgent while ignoring the failed request tied to the user’s action.
Avoid testing only on a wide desktop viewport. Test the important path with an ordinary phone width, a slow connection and an empty or expired session where those states are supported. Do not disable browser security features globally to make a request “work”; that hides the real deployment problem.
Finally, avoid copying a full Network export into a public issue without review. It may contain personal data, internal URLs or credentials in headers.
A small debugging record that pays off
For each incident, save five lines:
- Observed: what the user did and saw.
- Expected: what should have happened.
- Evidence: the first console error, request status or computed style that mattered.
- Change: the smallest source change made.
- Verification: the browsers, viewports and states tested afterwards.
This makes handoff easier and keeps the team from repeating the same investigation. It also turns a one-off fix into a future test case.
My Take
DevTools is most valuable when it makes you less imaginative. Instead of inventing a story about why the page fails, look at the DOM, the console, the request and the timeline in front of you. The goal is not to know every panel. It is to build the habit of asking one testable question at a time.
For a small site, that habit often beats a large rewrite. A missing asset, a wrong selector or an unhandled 403 does not need a new framework. It needs evidence, a focused fix and a check that the same user journey now works.
Bottom Line
When a website behaves strangely, follow this order: reproduce the exact problem, read the Console, inspect the live element, trace the relevant Network request, then record a Performance trace if speed is the issue. Make the fix in source code, protect any captured data and verify the real path again.
Sources: Chrome DevTools overview, Chrome Network panel overview, Chrome Performance panel overview, and MDN’s browser developer tools introduction.