The Network Tab

See what the page requests

The Network tab in DevTools lists files and requests the browser loads, such as scripts, stylesheets, images and API calls. Open it before reloading or repeating the action you are investigating; the panel records activity as it happens. This makes it useful in your bug-hunting quest when the app depends on a request that may be failing.

Rows include a resource name, type, status and timing information. Red or failed rows are a signal to investigate, not a complete diagnosis. Select a row to inspect details such as request headers, response headers and the response body.

Read status and response

The status code helps explain what happened. A 2xx status generally indicates success; 4xx means the request was rejected or the requested resource could not be found; 5xx indicates a server-side failure. A 404 specifically means the requested resource was not found. Check the URL and response body to understand the server’s explanation.

fetch('/api/profile')
  .then((res) => {
    console.log(res.status);
    return res.text();
  });

This small example illustrates inspecting a response; your quest may use a different request. In Network, the same request can be examined without adding logging to the app.

Find the failing part

A failed script request may stop page behaviour from loading. A failed API request may leave one panel empty while the rest of the app works. Filter by resource type or search for part of the URL to narrow the list, then compare the request URL, status and response body with what the app expects.

For the planted bugs, reproduce the failing action and inspect the corresponding Network row. Do not assume every visual problem is a network problem: if no relevant request appears, investigate the JavaScript path instead.

Use cache controls carefully

During development, enable Disable cache in the Network panel to make reloads fetch fresh resources while DevTools is open. This helps avoid testing an older cached script after you have edited a file. It is a development aid, not a setting to impose on ordinary users.

After correcting a URL, server response or app expectation, repeat the request and confirm the row now shows the expected outcome. Keep the response evidence in mind as you add the comment above each quest fix.

Rule out a missing file before fixing JavaScript

In the planted-bug activity, Network is a control check, not the cause of the three planted bugs. Open Network, reload your local page, and find index.html and app.js. A successful status tells you the files arrived; it does not prove the script contains correct logic.

Click app.js and inspect its Response and Initiator. Confirm the response is your current JavaScript, not an HTML error page, and the initiator is the expected page/script. A 404 points to a path problem. A 200 containing HTML can still cause a JavaScript syntax error. If app.js never appears, inspect the script tag before changing a loop.

Read a row in context

For an API request, record URL, method, status, response type and the body shape. Payload shows what you sent; Response shows what came back. Timing helps distinguish a slow request from expensive UI work after the request finishes. Preserve log can help follow navigation; Disable cache is a development setting while DevTools is open, not a product fix.

After ruling out missing files, use Console to find the first JavaScript failure and Sources to inspect values. A null selector, undefined name and off-by-one loop are not repaired by changing HTTP headers. Correct the source, rerun the same action and confirm the expected list and no errors.

Before the activity, demonstrate the actual script request and explain why status 200 is necessary but insufficient. Never share raw network exports containing auth headers, cookies or private responses; keep diagnostics limited to harmless practice requests.