Chrome Developer Tools hides detailed HTTP error responses by default to prevent clutter. To view the actual error message, open the Network tab, select the failed request, and click the Response or Preview tab in the bottom pane. This reveals the server’s body content, which is essential for diagnosing API failures.
Accessing the Network Tab
The foundation of debugging network issues lies in the Chrome DevTools Network panel. You must first ensure this panel is visible and capturing traffic. Press F12 or Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac) to open DevTools. Navigate to the Network tab at the top of the panel. If you do not see it, look for the row of tabs that includes Elements, Console, Sources, and others. Click on Network to activate it.
Once active, the panel will begin recording requests as you interact with the webpage. It is crucial to refresh the page (F5 or Cmd+R) if you want to capture initial load errors. Without a refresh, some early-stage connection errors might be missed because the tool starts listening after the page has already loaded its resources. Ensure the record button (a circle icon) is red, indicating that recording is active. If it is gray, click it to start capturing data.
Identifying Failed Requests
After refreshing the page, scan the list of requests for those with status codes starting with 4xx or 5xx. These entries are typically highlighted in red text within the Status column. The URL column shows the endpoint that failed. Common errors include 404 Not Found, 403 Forbidden, 500 Internal Server Error, and 502 Bad Gateway. Each code indicates a different type of problem, from missing resources to server-side crashes.
To investigate a specific error, click on the row corresponding to the failed request. This action populates the right-hand side of the DevTools window with detailed information about that specific transaction. Do not rely solely on the summary list; the individual request details contain the payload you need. If multiple requests fail, filter the list using the dropdown menu above the request table. Select All or use the Doc, XHR, or JS filters to narrow down the noise, focusing on XHR or Fetch requests if you are debugging an API call.
Viewing the Response Body
This is the most critical step for seeing the actual error message. In the main detail pane, scroll down to find the Response tab. By default, Chrome may show a preview or summary instead of the raw body. Click on the Response tab to switch views. Here, you will see the exact text returned by the server. For JSON APIs, this often contains a descriptive error message, stack trace, or validation failure details.
If the response is large, you can copy the entire body by right-clicking inside the pane and selecting Copy > Copy all as text. This allows you to paste the error into a text editor for closer inspection or share it with backend developers. Note that some servers return HTML error pages instead of JSON. In such cases, the Response tab will display the full HTML structure of the error page, which might include user-friendly messages or technical debug info embedded in comments.
For binary responses like images or fonts that fail to load, the Response tab may appear empty or show a placeholder. In these instances, check the Headers tab to verify the Content-Type and size. However, for textual API errors, the Response tab is your primary source of truth. If you cannot see the response body, ensure that the request was fully completed. Intermittent network drops might result in incomplete payloads.
Checking Headers and Cookies
Sometimes the error message in the body is vague, such as "Bad Request." In these scenarios, the Headers tab offers deeper context. Look at the Request Headers to verify authentication tokens, content types, and custom headers. A missing or expired JWT token often results in a 401 Unauthorized error, even if the server response body is minimal. Check the Authorization header specifically to ensure the token format is correct.
Additionally, inspect the Response Headers for clues. Headers like X-Error-Code or Retry-After can provide additional diagnostic information not present in the body. If you suspect caching issues causing stale error messages, clear the cache by checking the Disable cache box in the Network toolbar before making new requests. This ensures you are seeing the latest server response rather than a cached version of a previous error.
Preserving Logs Across Navigations
A common frustration is losing error logs when navigating to a new page or following a redirect. Chrome clears the Network log upon navigation by default. To retain these logs, locate the checkbox labeled Preserve log in the Network toolbar. Enable this option before triggering the error. This keeps the request history intact across page loads, allowing you to analyze pre-navigation errors alongside post-navigation ones.
This feature is particularly useful for debugging single-page applications where routing changes happen without a full page reload. However, be aware that enabling Preserve Log can cause memory usage to increase significantly over long sessions. Use it selectively when debugging specific flow issues rather than keeping it on permanently. For more complex debugging scenarios involving DOM updates, you might also find it helpful to review how static assets are handled, as seen in guides on How to Fix HTML Favicon Not Applied Issue.
Using the Console for Network Errors
While the Network tab provides granular detail, the Console tab can sometimes surface high-level network errors. Open the Console tab and look for red error messages related to fetch or XMLHttpRequest. These messages often summarize the issue but rarely include the full response body. They are best used for quick identification of blocked requests due to CORS policies or mixed content warnings.
CORS errors, for example, will explicitly state that the request was blocked by the browser's security policy. The console will not show the server's error message in this case because the browser prevents access to the response entirely. In such situations, you must fix the server configuration to allow the origin, as client-side tools cannot bypass CORS restrictions. For asynchronous logic errors that might trigger network calls, understanding lifecycle hooks is vital, similar to concepts discussed in The Mystery of UseEffect's Invisible Bug.
Frequently Asked Questions
Why is my Response tab empty for a 404 error?
Some servers do not send a body with 404 responses to save bandwidth. In these cases, the Response tab will appear blank. Check the Headers tab for any custom error codes or consult the server documentation to understand what payload is expected for specific status codes.
Can I see the error message if the request is blocked by CORS?
No. When a request is blocked by Cross-Origin Resource Sharing (CORS), the browser denies JavaScript access to the response body entirely. The console will only show a generic error message stating that the request was blocked. You must resolve the CORS configuration on the server side to view the actual error details.
How do I filter network requests by status code?
Chrome DevTools does not have a direct numeric filter for status codes in the toolbar. Instead, use the filter input box above the request list. Type status:4 or status:5 to filter for 4xx or 5xx errors respectively. This helps isolate problematic requests from successful ones quickly.
What should I do if the error message is truncated?
If the response body is very large, Chrome may truncate the view in the UI. Click the expand arrow next to the response content or use the Copy function to retrieve the full text. Alternatively, download the response as HAR file via the right-click context menu to analyze the complete data offline.
Does the Preview tab show different information than Response?
Yes. The Preview tab attempts to format the response for readability, displaying parsed JSON objects or formatted HTML. The Response tab shows the raw, unformatted string returned by the server. Use Preview for easier reading of structured data, but always verify against Response if the formatting looks incorrect or if you suspect encoding issues.