How to Use Chrome DevTools Network Tab to Debug API Requests and Response Headers

The Chrome DevTools Network tab is one of the most powerful diagnostic tools available to web developers and IT professionals. While most users are familiar with using DevTools to inspect HTML elements and CSS styles, the Network tab provides a real-time window into every HTTP request and response that your browser sends and receives. This makes it indispensable for debugging API integrations, diagnosing slow page loads, identifying failed requests, and understanding exactly what data is being transmitted between your browser and a server.

This guide provides a comprehensive walkthrough of using the Network tab to debug API requests, inspect response headers, analyse timing breakdowns, and simulate different network conditions—skills that are essential for anyone working with web applications, REST APIs, or single-page applications.

How to Open the Network Tab in Chrome DevTools

There are several ways to access the Network tab:

• Keyboard shortcut: Press Ctrl + Shift + I (Windows/Linux) or Cmd + Option + I (macOS) to open DevTools, then click the Network tab.
• Direct shortcut: Press Ctrl + Shift + J (Windows/Linux) or Cmd + Option + J (macOS) to open the Console, then switch to the Network tab.
• Right-click method: Right-click anywhere on the page, select Inspect, then click the Network tab.

Once the Network tab is open, refresh the page (press F5 or Ctrl + R) to begin capturing all network requests. The Network tab only records traffic that occurs while it is open—it does not retroactively capture requests that happened before you opened it.

Understanding the Network Tab Interface

The Network tab displays a table of every HTTP request made by the page. Each row represents a single request and includes the following columns by default:

Column	Description
Name	The filename or endpoint URL of the request.
Status	The HTTP status code returned by the server (e.g., 200, 301, 404, 500).
Type	The resource type (document, script, stylesheet, xhr, fetch, image, font, etc.).
Initiator	What triggered the request (e.g., a script file and line number, or the HTML parser).
Size	The transfer size (compressed) and the actual resource size (decompressed).
Time	Total time from request initiation to response completion.
Waterfall	A visual timeline showing when the request started and how long each phase took.

You can add additional columns by right-clicking the column header. Useful additions include Protocol (to identify HTTP/2 vs HTTP/1.1 requests), Domain (to group requests by server), and Response Headers columns for specific headers like Cache-Control or Content-Type.

Filtering Requests to Isolate API Calls

A typical web page makes dozens or hundreds of requests for images, stylesheets, scripts, fonts, and tracking pixels. To focus exclusively on API calls, use the filter toolbar at the top of the Network tab:

• Fetch/XHR filter: Click the Fetch/XHR button to show only XMLHttpRequest and Fetch API requests. This immediately isolates API calls from all other resources.
• Text filter: Type a keyword in the filter input field to match URLs containing that keyword. For example, typing /api/ shows only requests whose URL contains “/api/”.
• Status code filter: Use status-code:404 or status-code:500 to show only requests that returned specific error codes.
• Method filter: Use method:POST or method:PUT to show only requests using specific HTTP methods.
• Negative filters: Prefix any filter with - to exclude matches. For example, -status-code:200 shows only non-successful requests.

Combining filters is one of the most effective debugging techniques. Using Fetch/XHR with a -status-code:200 text filter instantly reveals every failed API call on the page.

Inspecting Request and Response Details

Clicking on any request in the Network tab opens a detailed side panel with several sub-tabs:

Headers Tab

The Headers tab is the most important for API debugging. It displays:

• General: The full Request URL, HTTP Method, Status Code, and the Remote Address (IP and port) of the server.
• Response Headers: Every header returned by the server, including Content-Type, Cache-Control, Set-Cookie, CORS headers (Access-Control-Allow-Origin), and security headers (Strict-Transport-Security, X-Content-Type-Options).
• Request Headers: Every header sent by the browser, including Authorization (bearer tokens), Content-Type, Cookie, and custom application headers.

Pay particular attention to CORS-related headers when debugging cross-origin API calls. If Access-Control-Allow-Origin is missing or set to a different domain, the browser will block the response, and you will see a CORS error in the Console.

Payload Tab

For POST, PUT, and PATCH requests, the Payload tab shows the data sent to the server. This includes:

• Form Data: For application/x-www-form-urlencoded or multipart/form-data requests, the payload is displayed as key-value pairs.
• Request Payload: For application/json requests, the JSON body is displayed in a collapsible, formatted tree view. Click View source to see the raw JSON string.
• Query String Parameters: For GET requests, query parameters from the URL are parsed and displayed here for easier reading.

This is invaluable when debugging form submissions or API calls where you suspect the client is sending incorrect data to the server.

Preview and Response Tabs

The Preview tab renders the response body in a formatted, interactive view. For JSON responses, this displays a collapsible tree that is much easier to navigate than raw text. For HTML responses, it renders the HTML in a mini browser frame.

The Response tab shows the raw, unformatted response body. This is useful when you need to copy the exact response text or when the Preview tab fails to render complex data structures.

Timing Tab

The Timing tab provides a detailed breakdown of how long each phase of the request took:

Phase	Description
Queueing	Time spent waiting because Chrome limits concurrent connections per domain (typically 6 for HTTP/1.1).
Stalled	Time spent waiting before the request could be sent, often due to proxy negotiation or disk cache lookups.
DNS Lookup	Time to resolve the domain name to an IP address.
Initial Connection	Time to establish the TCP connection (and TLS handshake for HTTPS).
Request Sent	Time to transmit the HTTP request to the server (usually negligible).
Waiting for server response (TTFB)	Time to First Byte—the most important metric. This measures server processing time.
Content Download	Time to download the response body.

A high TTFB (Time to First Byte) typically indicates a slow server-side process—a slow database query, an overloaded server, or an inefficient API endpoint. A high Content Download time, on the other hand, suggests a large response payload or a slow network connection.

Simulating Network Conditions with Throttling

The Network tab includes a throttling feature that simulates slow network connections. This is critical for testing how your web application behaves on mobile networks or in regions with poor connectivity.

To enable throttling:

1. Click the No throttling dropdown in the Network tab toolbar.
2. Select a preset: Fast 3G, Slow 3G, or Offline.
3. Reload the page and observe how request timing and page behaviour change.

You can also create custom throttling profiles by clicking Add in the throttling dropdown. Specify custom download speed, upload speed, and latency values to simulate specific real-world conditions (e.g., a satellite internet connection with high latency but reasonable bandwidth).

Debugging CORS Errors Using the Network Tab

Cross-Origin Resource Sharing (CORS) errors are among the most common issues when integrating third-party APIs. When a CORS error occurs, the browser blocks the response, and the Console displays a generic error message that often provides insufficient detail.

The Network tab provides far more diagnostic information:

1. Open the Network tab and reproduce the failed API call.
2. Look for the failed request—it may appear with a (cancelled) or (blocked:cors) status.
3. If the API uses preflight requests, look for an OPTIONS request immediately before the actual request. This preflight request is sent by the browser to ask the server whether the actual request is permitted.
4. Click the preflight OPTIONS request and inspect the Response Headers. Verify that Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers are present and correctly configured.

Common CORS issues include: the server not returning Access-Control-Allow-Origin at all, the header being set to a specific domain that does not match your origin, or the server not including the required custom headers in Access-Control-Allow-Headers. All of these can be diagnosed directly from the Network tab’s Headers view.

Copying Requests as cURL Commands

One of the most useful features of the Network tab is the ability to copy any request as a cURL command. This allows you to reproduce the exact request in a terminal, complete with all headers, cookies, and authentication tokens.

To copy a request as cURL:

1. Right-click the request in the Network tab.
2. Navigate to Copy > Copy as cURL.
3. Paste the command into a terminal and execute it.

This is particularly valuable for sharing reproducible bug reports with backend developers. Instead of describing a failed API call, you can provide the exact cURL command that reproduces the issue. You can also use Copy as fetch to get a JavaScript Fetch API equivalent, or Copy as PowerShell for Windows environments.

Preserving Logs Across Page Navigations

By default, the Network tab clears all recorded requests when you navigate to a new page. This makes it impossible to debug redirects, form submissions that navigate to a new URL, or OAuth authentication flows that involve multiple page transitions.

To preserve logs across navigations, tick the Preserve log checkbox in the Network tab toolbar. With this enabled, all requests remain visible even after page transitions, allowing you to trace the complete request chain from start to finish.

Blocking Specific Requests for Testing

Chrome DevTools allows you to block specific URLs or URL patterns to test how your application handles failed dependencies. This is invaluable for testing graceful degradation—for example, verifying that your page still loads correctly if a third-party analytics script fails.

To block a request:

1. Right-click a request in the Network tab.
2. Select Block request URL or Block request domain.
3. Reload the page to see the effect.

You can manage all blocked URLs from the Network request blocking panel (accessible via the DevTools command menu: Ctrl + Shift + P and search for “Show Network request blocking”). Blocked requests appear with a (blocked:devtools) status in the Network tab.

Exporting Network Data as a HAR File

HTTP Archive (HAR) files capture a complete record of all network requests, responses, headers, timing data, and response bodies. This is the standard format for sharing network diagnostic data with other developers or support teams.

To export a HAR file:

1. Reproduce the issue while the Network tab is recording.
2. Click the download icon (down arrow) in the Network tab toolbar, or right-click in the request list and select Save all as HAR with Content.
3. Save the .har file.

HAR files can be analysed using tools like Google’s HAR Analyser or imported into another Chrome DevTools instance. Be cautious when sharing HAR files externally, as they may contain sensitive data including authentication tokens, cookies, and session identifiers.