
Master the Network Tab: Debug API Calls Like a Detective
When your API returns unexpected data, the Network tab is your best friend. Learn to inspect requests, responses, headers, and timing.

When your API returns unexpected data, the Network tab is your best friend. Learn to inspect requests, responses, headers, and timing.
Establishing TCP connection is expensive. Reuse it for multiple requests.

HTTP is Walkie-Talkie (Over). WebSocket is Phone (Hello). The secret tech behind Chat and Stock Charts.

IP addresses change like home addresses. MAC addresses are like DNA or Fingerprints. Burned into hardware.

OSI 7 Layer is Theory. TCP/IP 4 Layer is Reality. Pragmatism beats Perfectionism.

Mid-project, I hit this wall. The backend API worked perfectly in Postman. Clean 200 OK, data exactly as expected. But when I called it with fetch in the actual web app? Failure. Console showed CORS error, data came back as undefined.
At first, I blamed my code. Re-checked the fetch syntax, shuffled async/await order, added try-catch blocks. Same error. Asked the backend team—got back "Works fine in Postman though."
Finally, I opened the Network tab in browser DevTools to see what was actually happening. And there it was. The request went out fine, but the server's response headers were missing Access-Control-Allow-Origin. Postman doesn't care about CORS because it's not a browser. The problem wasn't my code—it was server configuration.
That's when it clicked. The Network tab is the black box that shows truth between code and server. When your code claims "I sent the request" and the server claims "I responded fine," the Network tab shows you what actually happened, no lies.
Open the Network tab and you'll see every HTTP request listed chronologically. Click on any request and detailed info appears on the right. Here are the tabs that matter.
The Headers tab is like a passport for your request and response. It shows where it came from, what credentials it has, what it's asking for.
In Request Headers, check:Authorization: Is the token actually attached?Content-Type: Is it application/json or application/x-www-form-urlencoded?Origin: The browser auto-attaches this (used for CORS decisions)Access-Control-Allow-Origin: Is CORS allowed?Content-Type: What format did the server send? (If you expected JSON but got HTML, it's probably an error page)Set-Cookie: Are cookies being set properly?// Example: Sending request with Authorization header
fetch('/api/user/profile', {
headers: {
'Authorization': `Bearer ${token}`,
'Content-Type': 'application/json'
}
})
Click on this request in the Network tab and you'll see if Authorization: Bearer eyJhbGc... actually got sent. I've seen cases where the code clearly sets the token but null gets transmitted. Usually a variable scope or timing issue.
Preview formats JSON nicely, shows it as a tree structure. Great for inspecting deeply nested data.
Response shows the raw output. If the server sent an HTML error page instead of JSON, you'll catch it here.
Once, an API returned { "data": null } and I couldn't figure out why. Looked at the Response tab—turns out it was { "data": null, "error": "Invalid token" }. My code was only looking at response.data, so I missed the error message.
The Timing tab breaks down the request lifecycle into milliseconds. Like a slow-motion replay of a race.
When a page feels slow, Timing tells you why. If TTFB is 5 seconds, the server's slow. If Content Download is 5 seconds, it's network or data size.
// Example: Timing a slow API call
async function loadUserData() {
const start = performance.now();
const response = await fetch('/api/users/list');
const data = await response.json();
const end = performance.now();
console.log(`Total time: ${end - start}ms`);
// Compare with Network tab Timing to see where the delay is
}
Status codes are the server's facial expressions. Even within the 400s, meanings differ.
Real-world confusion I had: After login, dashboard kept returning 401. Login succeeded, so why 401? Network tab showed the login API returned 200, but the next dashboard API request had no token in headers. The code that saved the token to localStorage after login had an async timing issue and ran too late.
Load one web page and dozens of requests fly—images, CSS, JS, fonts, analytics. To see just the API calls you care about, use filters.
Fetch/XHR filter to show only API requests/api/user) to filter specific requestsWhen a page redirects or refreshes, the Network tab clears. Turn on the Preserve log checkbox and previous requests stay visible after page transitions.
Essential for debugging login flows with redirects. You can see if the login POST succeeded, then which request failed afterward—the whole sequence.
Right-click a request and select Copy > Copy as cURL to get a terminal-executable cURL command. It includes headers, cookies, body—everything needed to reproduce the exact same request.
When reporting bugs to backend teams, send this. Cuts out the "How did you make the request?" back-and-forth. They can run the exact same request and see it themselves.
# Copy as cURL example (actual output)
curl 'https://api.example.com/users/123' \
-H 'Authorization: Bearer eyJhbGc...' \
-H 'Content-Type: application/json' \
--compressed
At the top of the Network tab, there's a Throttling dropdown. Select options like Fast 3G or Slow 3G to artificially slow down your network.
Test how the UI looks when images load slowly, or how user experience degrades when API responses take 5 seconds. Useful for checking if loading spinners show up, if timeout handling works.
Code can claim "I sent it," the server can claim "I received it." But what actually happened? Only the Network tab knows.
The core of API debugging is observation, not guessing. Not "I think the header wasn't attached," but opening the Headers tab to actually check. Not "The server's probably slow," but looking at Timing to measure TTFB.
The Network tab is like a detective's dashcam. It reconstructs the crime scene accurately. Go through Headers, Preview, Response, Timing tabs in order, and you can trace exactly where and how a request failed—or succeeded but gave unexpected results.
Next time someone says "Works in Postman but not in the browser," open the Network tab first. The answer's in there.