Chrome DevTools Network Tab: Complete Developer Guide
The Network tab is where most frontend bugs are actually solved. A blank screen, a spinner that never ends, a form that "does nothing": open the Network tab and the answer is usually one row away. Most developers use about a fifth of it. This guide goes through the rest: the filters, the details panes, the right-click menu, and the features hidden under More tools.
Everything here is Chrome's DevTools, and the same in Edge and other Chromium browsers. Firefox's Network Monitor has most of the same features under slightly different names.
Opening it, and the first trap
Open DevTools with F12, Ctrl+Shift+I (Windows, Linux) or Cmd+Option+I (macOS), then pick Network. You can also right-click anything on the page, choose Inspect, and switch tabs.
The first trap: the Network tab only records while DevTools is open. Requests made before you opened it are not there. Reload the page (Ctrl+R / Cmd+R) with DevTools open to capture everything from the first byte.
The toolbar
From left to right, the controls you will use most:
- Record (
Ctrl+E/Cmd+E): stop recording to freeze the list while you inspect it. - Clear (
Ctrl+L/Cmd+Kon macOS): empty the list before reproducing a bug, so only the relevant requests are left. - Preserve log: keep requests across navigations. Without it, a redirect or a form submit that reloads the page wipes the request you wanted to see. Turn it on for login flows and anything that navigates.
- Disable cache: skip the HTTP cache while DevTools is open. Use it when you are asking "did my change deploy?" and want every file fetched fresh.
- Throttling: the dropdown that says No throttling. Presets such as Fast 4G, Slow 4G and 3G slow every request down, and Offline cuts the tab off. You can add your own profile with custom download, upload and latency.
- Import / Export HAR: the up and down arrows. More on HAR files below.
The gear icon on the right holds four display settings worth knowing: Big request rows (two lines per row: transferred and real size, time and latency), Show overview (the timeline strip at the top), Group by frame, and Capture screenshots (filmstrip of the page as it loads).
Filtering: find the one request
A busy page makes hundreds of requests. The filter row is how you find yours.
Type buttons. All, Fetch/XHR, Doc, CSS, JS, Font, Img, Media, Manifest, Socket, Wasm, Other. For API debugging, Fetch/XHR is the one. Ctrl+click (or Cmd+click) selects several.
Text filter. Type part of the url. Wrap it in slashes for a regular expression (/api\/v[12]\//), prefix it with - to hide what matches (-analytics), or tick Invert.
Property filters. The filter box understands property:value, and this is the part most people never discover. Start typing and DevTools suggests them:
| Filter | Shows |
|---|---|
status-code:500 | Responses with that status |
method:POST | Requests with that method |
domain:api.example.com | Requests to that host (*.example.com works) |
-domain:*.google-analytics.com | Everything except that host |
mime-type:application/json | Responses of that type |
larger-than:100k | Responses bigger than 100 KB |
has-response-header:Set-Cookie | Responses carrying that header |
is:running | Requests still in flight |
scheme:http | Requests not on https |
Combine them with spaces: method:POST status-code:422 domain:api.example.com is every failed form submit to your API.
Search. Ctrl+F / Cmd+F with the Network tab focused opens a search across urls, headers and response bodies. When you know a value is on screen but not which request delivered it, search for the value.
Reading the request list
The default columns are Name, Status, Type, Initiator, Size, Time and Waterfall. Right-click any column header to add more: Method, Domain, Protocol (spot an HTTP/1.1 request among HTTP/2 ones), Priority, Remote address, or any response header you name under Response Headers > Manage header columns.
A few values worth recognising:
- Status in red,
(failed),(canceled),(blocked:...): the request never got a normal answer. Hover it, or open it, for thenet::ERR_...reason. CORS errorin the Status column: the server answered, but the browser refused to hand the response to the page. See How to fix CORS errors in your browser.- Size
(memory cache)or(disk cache): nothing came over the network. If you expected a fresh response, this is why you are not seeing your change. - Size
(ServiceWorker): a service worker answered the request. If your app uses one (or Mock Service Worker), this is where its responses show up. - A row with method
OPTIONSright before your request: a CORS preflight.
Initiator tells you who made the request: a script with a line number, a stylesheet, the parser. Hover it for the full JavaScript call stack, and click a frame to jump to the code. Hold Shift while hovering a row to colour its initiators green and the requests it caused red.
Inspecting one request
Click a row to open its details. The tabs:
Headers. The url, method, status and remote address at the top, then Response Headers and Request Headers. Toggle Raw to see them exactly as sent. A yellow "Provisional headers are shown" warning means DevTools did not see the final request (served from cache, or blocked before it left); the headers listed are what the browser intended to send.
Payload. What you sent: query string parameters, the JSON body, form fields. View source shows the raw body, View parsed a tree. If the server says your request is wrong, check here before you check the server.
Preview. The response, formatted: a collapsible tree for JSON, a rendered image, a rendered HTML page.
Response. The raw response body. On a large minified JSON, the {} button at the bottom pretty-prints it.
Initiator. The same call stack as the column, plus the chain of requests that led to this one.
Timing. Where the time went, phase by phase:
| Phase | A long one usually means |
|---|---|
| Queueing / Stalled | Too many requests to one host at once, or a lower priority |
| DNS Lookup | A new domain; consider dns-prefetch or preconnect |
| Initial connection, SSL | A new connection; reuse connections, preconnect |
| Request sent | A large upload |
| Waiting for server response | The server is slow to start answering (time to first byte) |
| Content Download | A large response, or a slow connection |
Cookies. The cookies sent and set by this request, and the reason any was blocked (SameSite, Secure, third-party restrictions).
Messages (WebSockets) and EventStream (server-sent events) appear for those requests and list each message as it arrives.
The right-click menu
Right-click a request for the actions that make the Network tab a tool rather than a log:
- Copy > Copy as cURL: the exact request, headers and cookies included, as a terminal command. Paste it in a bug report and the backend developer can reproduce it without your browser. Copy as fetch and Copy as Node.js fetch do the same in JavaScript.
- Copy > Copy response: the body, ready to paste into a fixture or a mock.
- Replay XHR (on Fetch/XHR requests): send it again, as is. Handy after a backend fix.
- Block request URL / Block request domain: the request fails from now on, with a network error. Quick check of "what breaks when this script does not load?"
- Override content / Override headers: see local overrides below.
- Save all as HAR: export the whole list.
Copying a request with credentials (cURL, fetch, HAR) copies your cookies and tokens too. Treat the result like a password.
Features under More tools
Open them from the DevTools menu (the three dots) > More tools, or with the command menu (Ctrl+Shift+P / Cmd+Shift+P) and their name.
Network request blocking. A list of url patterns (*/api/recommendations*) that all fail while the panel is enabled. Easier to manage than the right-click action when you block several things.
Network conditions. Change the user agent (test what your server does for a mobile browser or a bot), turn off the cache, pick a throttling profile, and set the Accept-Language the browser sends.
Local overrides: change a response
Local overrides let you replace a response with a file on your disk, and the replacement survives reloads.
- Right-click a request and pick Override content.
- The first time, DevTools asks for a folder to keep overrides in, and permission to use it.
- Edit the response in the Sources panel and save. The request now shows a purple dot in the Network tab, and the page receives your version.
Override headers does the same for response headers. Overrides are good for one quick experiment on a single file: a changed script, a stylesheet, a JSON response.
HAR files: share a whole session
A HAR file is the Network tab saved to disk: every request, header, timing and (optionally) body. Export one with the down-arrow icon, and someone else can import it with the up-arrow and inspect your session as if they had been there. It is the best attachment for a "it fails for me" bug report. Recent versions of Chrome leave sensitive data such as cookies out of the export by default; still read a HAR before you share it. We wrote a whole post on what a HAR file tells a developer.
Where the Network tab stops
The Network tab is excellent at observing traffic. It is limited at changing it:
- Blocking only produces network errors. You cannot make an endpoint return a
500, a401or a429to see your error screens. - Overrides cannot change the status code, take a few steps per request, need a local folder, and only apply while DevTools is open.
- It cannot change a request before it is sent: its url, its body, a header the page sets.
- Nothing is shared. Your overrides and blocked patterns live in your DevTools, not in a file the team can reuse.
This is the gap a browser extension like tweak fills, and it works next to DevTools rather than instead of it:
- Mock rules return any status, body, headers and delay for a url, without DevTools open. See How to test error states in your frontend application.
- Modify rules take the real response and change one field, the status or a header (Tweak Basic and Tweak Max).
- Headers only rules, redirect rules and block rules are applied by the browser itself, on every request type, page navigations included.
- Pause & Edit holds a request before it is sent so you can edit it (Tweak Max).
- Request capture records what the tab sends and turns any request into a rule in one pick, and a HAR file exported from the Network tab imports as rules on every plan.
Cheat sheet
| Task | How |
|---|---|
| See requests from page load | Open DevTools, then reload |
| Keep requests across a redirect | Preserve log |
| Only API calls | Fetch/XHR type button |
| Only failures | status-code:500 (or -status-code:200) |
| Hide analytics noise | -domain:*.google-analytics.com |
| Find which request returned a value | Ctrl+F / Cmd+F, search response bodies |
| Why is it slow? | Timing tab |
| Who made this request? | Initiator column, hover for the stack |
| Reproduce it in a terminal | Right-click > Copy as cURL |
| What breaks without it? | Right-click > Block request URL |
| Test on a slow network | Throttling dropdown |
| Share the session | Export HAR |
Return a 500 / change a response for good | A tweak Mock rule |
If you liked this article, consider sharing (tweeting) it to your followers.
Need something else? Request a feature