Watching a request in the browser's developer tools
On This Lesson 11 topics
Lesson Overview
So far you have learned the journey of a request in theory. In this lesson you will watch it happen. Every modern browser includes developer tools: a built-in toolbox for people who build websites. One tool, the Network panel, lists every request the browser makes while loading a page, along with each response.
Seeing a real GET and a real 200 turns the diagram from Lesson 4 into something you have actually observed. It also gives you a skill you will use for the rest of your career: when a page misbehaves, the Network panel is usually the first place a backend developer looks to see what the browser really asked for and what the server really answered.
This lesson is hands-on. The menus, shortcuts, and layout of developer tools differ between browsers, operating systems, and versions, and they change over time. We describe what is common and tell you where to adapt. If something looks different on your screen, search for "open Network tab" with your browser's name.
This lesson builds on Lesson 4 (requests, responses, and status codes) and Lesson 5 (HTTPS).
Learning Objectives
By the end of this lesson you will be able to:
- Open your browser's developer tools and find the Network panel.
- Explain why you must open the panel before loading the page.
- Reload a page and read the list of requests it produced.
- Read the method, status code, and type of a request.
- Identify the main document request.
- Open a request's details to see its headers.
- Describe at least two other things the panel can show, such as size and timing.
Written Explanation
What are developer tools?
Developer tools (often shortened to DevTools) are a set of panels built into browsers such as Chrome, Edge, Firefox, and Safari. They show what is happening inside the page and the browser. Typical panels include:
- Elements (or Inspector): the page's structure.
- Console: messages and errors from the page's scripts.
- Network: the requests the browser makes and the responses it gets.
You can open the tools on any page. Looking at them changes nothing for anyone but you, and you are only viewing what your own browser received. This is a safe place to explore.
Opening the Network panel
The menu names and key combinations depend on the browser and operating system. Common ways to open DevTools:
- Press
F12on most Windows and Linux browsers. (This is widely used, but if it does nothing on your machine, use one of the options below.) - In Chrome, the Chrome DevTools documentation gives
Ctrl+Shift+Jon Windows and Linux andCommand+Option+Jon macOS, then you click the Network tab. - In Firefox, the Firefox documentation gives
Ctrl+Shift+Eon Windows and Linux andCmd+Opt+Eon macOS to open the Network Monitor directly. - You can also right-click on a page, choose Inspect (or similar), and then pick the Network tab.
Panel names vary slightly: Firefox calls it the Network Monitor, and Safari may require you to enable developer features in its settings first. Search for your browser's name plus "developer tools" if needed.
The tools may open docked to the side or bottom of the window, or in their own window. All are fine.
Open it first, then load
The Chrome documentation explains that DevTools only records network activity while it is open. If you open the panel after the page has loaded, the list is empty because the requests already happened. So the routine is:
- Open the page, or an empty tab.
- Open DevTools and select the Network panel.
- Reload the page (or enter the address and press Enter).
- Read the list.
Reloading with the panel open gives you a fresh recording of every request.
A note on caching: the browser may reuse files it already downloaded, so some rows may show as served from a cache rather than from the network. Many browsers offer a "Disable cache" checkbox in the Network panel and a "hard reload" option that fetches everything again. Names vary by browser, so look for them if you want a full, uncached picture.
Reading the request list
After the reload, the Network panel shows a table. Each row is one request, usually in the order the browser made them. The Chrome documentation lists these default columns:
| Column | What it shows |
|---|---|
| Status | The HTTP status code of the response (for example 200) |
| Type | The kind of resource (document, stylesheet, script, image, and so on) |
| Size | How much data was transferred over the network |
| Time | How long the request took |
| Initiator | What caused the request, for example the HTML page or a script |
| Name | The file or resource requested (hovering shows the full URL) |
Browsers differ in their column sets. A Method column (showing GET, POST, and so on) is not always visible by default. In many browsers you can add it by right-clicking the column headings and choosing which columns to show, but the exact option depends on your browser. If you cannot find it, you can always read the method from the request's details, as described next.
The main document
When you load a page, the first row is usually the main document: the request for the page's HTML (Lesson 4). Its Type is usually shown as document. In a normal load, the other rows are requests the browser made after reading the HTML: stylesheets, scripts, images, and so on.
This first row is the one the lab asks you to examine. Typically you will see:
- Method:
GET - Status:
200 - Type:
document
Do not worry if you see something different. A site may first answer with a redirect such as 301 or 302 (for example from http:// to https://, or from a bare domain to the www version). Then the first row is the redirect, and a later row is the page that finally arrives. Looking at both rows is a good way to understand what the site does.
Opening a request's details
Click a row to open its details pane. The Chrome documentation says the Headers tab shows the request's HTTP headers. Common tabs include:
- Headers: the request line and the request headers you send, and the response headers you receive. The general section usually includes the full URL, the request method, and the status code. The exact labels differ by browser.
- Preview or Response: the content that came back, such as HTML text or an image.
- Timing: how long each phase of the request took.
- Initiator: what triggered the request.
From the Headers tab you can read the HTTP messages from Lesson 4. For the response, look for the Content-Type header, which tells the browser what kind of content the body holds. For the request, look for the Host header and the headers that describe the browser, for example the language preferences.
Reading a few common patterns
| What you see | What it usually means |
|---|---|
| Many rows for one page | A page is made of many resources, one request each |
Status 200 | The request succeeded |
Status 301 or 302, then another row | A redirect: the server told the browser to go somewhere else |
Status 304 | Not modified: the browser may reuse its cached copy |
Status 404 on one row | That one resource was not found, even if the main page loaded |
Status 500 or 503 | The server had a problem |
| A row to a different domain | The page uses resources from another server |
Filtering and sorting
For busy pages, DevTools offers filter buttons (for example Document, Stylesheets, Scripts, Images) and a text filter. Choosing Document is a quick way to find the main document. You can usually also click a column heading to sort. These controls are stable in spirit but their labels differ between browsers.
What you can see, and what you should leave alone
The Network panel shows your own browsing data, including headers that may contain cookies or tokens for sites you are logged into. Do not share screenshots of headers or responses that include such values. For the lab, use a simple public site and take screenshots of that.
Examples
Example 1: Finding the status of one request (simple)
You open https://example.com in a browser, open the Network panel, and reload.
- The list shows one main row with the name of the site.
- The Status column shows
200. - The Type column shows
document.
You click the row. The Headers tab shows the full URL, the request method GET, and the status code 200. The response headers include Content-Type with a value that names HTML. This confirms that the browser asked for a page with GET and the server replied with the page.
The address example.com is reserved by the Internet Assigned Numbers Authority for use in documentation, so it is a good safe site to practise on. A very simple page like this one produces few rows, which makes the list easy to read. (If it shows more or different rows than you expect, that is normal. Sites and caches change.)
Example 2: A redirect (practical)
You type http://example.com with http, not https, and watch the Network panel. Some sites answer the first request with a redirect status, 301 or 302, and a header that tells the browser the new address. The next row is then a request to the https:// address that answers with 200.
What to learn: a single URL typed by a user can produce two or more requests. The first row is not always the page. Reading the Status column row by row lets you follow the chain. Not every site behaves this way, and the result may depend on your browser, since some browsers upgrade http to https themselves before sending anything. If you see no redirect, that is also a valid result.
Example 3: Finding a broken image (realistic)
A colleague reports "the product page has a missing picture". You open the page with the Network panel open and reload. You filter by Images, then scan the Status column. Eleven images show 200. One shows 404.
You click the 404 row and read its URL: the path has a typo, /imgs/boots-blu.png where the files are stored under /images/. The main document is fine and the server is healthy. The mistake is in the HTML or in a database value that stores the image path.
Without the Network panel, you would have guessed. With it, you found the exact request that failed, the status code, and the faulty address in under a minute. This is the daily use of the tool: compare what the browser asked for with what the server answered.
Backend Insight
The Network panel is a window onto the other side of your backend. Every request the browser shows is a request your server might receive, and every response is one your server might send. As a backend developer you will use it to:
- Check status codes. Did your endpoint really return
201or404as you intended? - Check the method. Is the front end calling
POSTwhere you expectPOST? - Check the body and headers. Did the browser send the right data? Is the
Content-Typeof your response correct? - Spot slowness. The Time column and Timing tab show which request is slow. A slow response might point to your database query.
- Reproduce problems. You can often copy a request from the panel and replay it with another tool. That is a topic for later modules.
A good habit: when something looks wrong in the page, check the Network panel before changing any code. The panel tells you whether the problem is a failed request, a wrong response, or a front-end bug that never sent a request at all.
Common Mistakes
Mistake 1: Opening DevTools after the page loaded
The panel records only while it is open. An empty list usually means you opened it too late. Reload with the panel open.
Mistake 2: Assuming the first row is always a 200 page
Redirects and cached responses can change what you see. Read the status of each row.
Mistake 3: Ignoring the cache
A resource served from cache shows no real network time. For a full picture use the option that disables the cache, while DevTools is open.
Mistake 4: Sharing screenshots with secrets
Headers can hold cookies and tokens. Crop or avoid screenshots that show them.
Mistake 5: Confusing a failed resource with a failed page
One 404 on an image does not mean the page failed. Check which row has the problem.
Exercises
Try each exercise yourself before opening the solutions.
Level A: Foundation
A1. Why must the Network panel be open before you load the page?
Show solution A1
A1. DevTools records network activity only while it is open, so requests made before opening are not recorded.
A2. In the Network panel, what does one row represent?
Show solution A2
A2. One request made by the browser, together with its response.
A3. Which column shows the HTTP status code?
Show solution A3
A3. The Status column.
Level B: Application
B1. You open the Network panel on a page that has already loaded, and it is empty. What do you do?
Show solution B1
B1. Keep the panel open and reload the page (or enter the address again) to record a fresh load.
B2. The first row has status 301, and the second row has status 200. Describe what happened.
Show solution B2
B2. The server answered the first request with a permanent redirect, telling the browser to use another URL. The browser then requested the new URL, and the server answered 200 with the content.
B3. You want only the main HTML document from a busy list of requests. Describe two ways to find it.
Show solution B3
B3. The main document is normally the first row and has type document. You can also use the Document filter button, or the text filter, to show only document requests.
Level C: Challenge
C1. A page loads and looks fine, but one row shows status 500. Explain what that tells you and which side must fix it. What information from the row would you give the backend team?
Show solution C1
C1. A 500 is a server error, so the backend side must investigate. Give the team the full URL, the method, the time of the request, and, if safe to share, the response content. Do not share cookies or tokens.
C2. The same site loaded faster on the second visit and many rows show a cache indicator. Explain why, and how you would force a full download to measure the real first-visit time.
Show solution C2
C2. The browser reused files it had already stored (the cache), so less data came over the network. To measure a first visit, enable the "disable cache" option while DevTools is open, or do a hard reload, so the browser fetches everything again. The labels vary between browsers.
Mini Challenge
Practise on a simple public site.
- Open
https://example.com(or another simple public page) in a browser tab. - Open the Network panel, then reload the page.
- Write down the number of rows and the Type of each one.
- For the main document row, write down the method, the status code, and the type. If you cannot find the method in the list, open the row's details and look at the Headers tab.
- Write down one request header and one response header you can see, and what each does, in your own words.
- Filter to the Document type and confirm you see the same row.
Check your work: your answers for step 4 use the names Method, Status, and Type, and you did not copy any cookies or tokens into your notes.
Summary & Next Lesson
Key takeaways
- The Network panel in developer tools lists every request the browser makes and the response to each.
- Open the panel before loading the page, then reload.
- Each row is one request. Look at Status, Type, Size, and Time, and open a row for headers.
- The main document is usually the first row, with type
document. - Redirects, caches, and different browsers can change what you see. Read the rows rather than assuming.
- Backend developers use the panel to check status codes, methods, and slow requests.
Next lesson
You now know both halves: how to look up an address and how to watch a request. The next lesson, "Demo: following a URL with nslookup and the Network tab", combines them into one hands-on walkthrough that prepares the lab.
Self-check
- What is the Network panel for?
- When should you open it, before or after loading the page?
- How do you find the status code of a request?
- What type does the main HTML request usually have?
- Does a
404on one image mean the whole page failed?
Show answers
- Seeing the requests the browser makes and the responses it receives.
- Before, then reload the page.
- Read the Status column, or open the request's Headers details.
document.- No. Only that resource failed. The page itself may have loaded fine.
References
- Chrome for Developers, Inspect network activity. Supports opening the Network panel with the documented shortcuts, the point that DevTools logs only while open, reloading to record, the Status, Type, Size, Time, and Initiator columns, and the Headers tab. It did not cover the Method column or the cache options in the text I read, so those parts are hedged.
- Firefox Source Docs, Network Monitor. Supports the Firefox shortcut for opening the Network Monitor. It did not list columns on that page.
- Mozilla Developer Network, HTTP response status codes. Supports the meanings of 200, 301, 302, 304, 404, 500, and 503.
- IANA, Example domains. Supports
example.combeing maintained for documentation use. The use ofF12, the Safari note, and the Method column and Disable cache options are standard practice that I could not verify on a specific page, so check your own browser.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.