How a Server Works: The Request, Process, Response Cycle

by Souy Soeng /October 18, 2026

Diagram of a browser sending a request to a server, which processes it and returns a response, labeled request, process, response

How a server works comes down to one repeating cycle: your browser sends a request, the server processes it, and the server sends a response back. Every time you open a website, this happens in under a second, and the same three steps sit behind every web page you visit.

This guide walks through each step in order, using the same examples as the video: a short HTTP request, a look inside the server, and the response your browser turns into a page. You will then check the cycle yourself in your browser's developer tools and learn what the 404 and 500 error codes are telling you. You do not need to install anything or write any code.

In short

Your browser is the client that asks; the server is another computer that answers.
Step one: the browser sends a short HTTP request, such as GET /index.html.
Step two: the server reads the request, runs code, and may query a database.
Step three: the server returns a status code and the page content.
You can watch every request in the Network tab; 200 OK means the cycle worked.

Know the two sides: client and server

Before following a request, it helps to name the two parties in the conversation. Your web browser is the client: it is the side that asks for something. A server is simply another computer: it is the side that answers. Everything in this guide builds on that one idea of a question going out and an answer coming back.

The goal is to understand how a server receives a request, processes it and sends a response, from start to finish, without needing any code of your own. That makes this a good starting point whether you are curious about the web or about to build your first site.

You also need very little to follow along. Chrome, Firefox, Edge and Safari all ship with developer tools, so the browser you already use is enough to check every step yourself. There is nothing to download or set up.

A browser is the client: it asks
A server is another computer: it answers
Any modern web browser to test with
Its built-in developer tools, no installs needed

Send a request with HTTP

Step one starts with you. When you type an address and press Enter, your browser asks the server for a page using a shared language called HTTP. That request is not anything mysterious: it is a short text message. The example below shows roughly what your browser writes on your behalf.

The line GET /index.html says, in effect, "please give me this page, using HTTP." GET is the method, and it tells the server what you want to do. GET means fetch, and it is the most common method, used every time you simply open a page. Other methods exist for other jobs, such as POST for sending a form.

The Host line names the website, here example.com. This matters because one server can host many websites at once, so the server needs to know which one you mean. The Accept line says what kind of content the browser wants back, in this case an HTML page. Your browser builds this message automatically every time you click a link, so you never write it by hand.

The method (GET) says what you want to do
The path (/index.html) says which page you want
Host tells a shared server which website you mean
Accept says what kind of content to send back

# The browser asks for a page
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html

Process the request on the server

Once the request arrives, step two happens out of sight. The web server reads the message and works out which page you want. It then hands off to the app code, which decides what the answer should be. If that answer depends on stored information, the app code queries a database and gets the data back.

A profile page is a good example. When you open your own profile, the app code asks the database for your name and photo, then builds a page with those details filled in, just for you. That is why two people can visit the same address and see different content.

Not every request needs a database, though. A simple page can be sent straight from a file on the server with no extra work. Either way, the purpose of this step is the same: turn your question into an answer that is ready to send back.

The web server reads the request and finds the page
App code decides what the answer should be
A database is queried only when stored data is needed
Simple pages can come straight from a file

Return a response to the browser

With the answer ready, step three sends it home. Like the request, the response is a short text message, followed by the page itself. It has two key parts: a status code that says how things went, and the page content your browser will display.

In the example below, HTTP/1.1 200 OK is the status line, and it means everything went fine. The status code is always a three-digit number, and 200 means success. The Content-Type line tells the browser that what follows is an HTML page, so it knows how to handle it. After that comes the page content itself.

Your browser reads that HTML and draws the page on your screen. While doing so, it may send more requests for images and styles, each of which goes through the same cycle. At this point the loop is complete: you asked, the server worked, and the answer arrived.

The status line comes first and reports the result
Content-Type says what kind of content follows
The HTML is what your browser draws
Images and styles may trigger extra requests

# The server answers
HTTP/1.1 200 OK
Content-Type: text/html
# then the page content:
<html>…</html>

Check for 200 OK in your browser's Network tab

So far the three steps have been on paper. Your browser's developer tools let you watch them happen for real, because they record every request and response. You can follow along on any website, but example.com is a simple place to start.

Open developer tools by pressing F12, or right-click the page and choose Inspect. Click the Network tab, then reload the page. You will see a GET request for / appear in the list. Look at the status column and you should see 200 OK, which means the whole cycle just worked.

Click any row to see the request your browser sent and the response the server returned, side by side. These are the same kinds of lines shown in the examples above. Do not be surprised by a long list: each image and style file needs its own request and response, so many rows is completely normal.

Open DevTools with F12 or right-click and Inspect
Select the Network tab
Reload the page and find GET /
Confirm the status column shows 200 OK
Click a row to compare request and response headers

Fix 404 and 500 errors using the status code

Sometimes the status column will not say 200. When that happens, the code itself tells you where to look, because it points to the step that went wrong. Three codes cover most of what you will run into at first.

A 404 means not found. The server is working fine, but the page you asked for is not there. The usual cause is the address, so check the URL for typos. A 500 means a server problem: something broke while the server was processing the request, such as the code crashing. In that case the place to look is the server logs.

A simple rule helps here: a 404 usually means the address is wrong, while a 500 means something failed on the server side. Knowing which step failed saves you a lot of guessing and sends you straight to the right fix.

200 OK: the request worked, nothing to fix
404: page not found, check the URL for typos
500: server problem, check the server logs
404 points to the address; 500 points to the server

Put the full request-response cycle together

Now you can see the whole journey in one place. Your browser is the client and the server is another computer that answers. First, the browser sends a request using HTTP. Second, the server processes it: it reads the request, runs code, and may query a database. Third, it returns a status code and the page.

You can confirm the cycle at any time by looking for 200 OK in the Network tab. If it fails, the status code tells you where to start: a 404 means check the URL, and a 500 means check the logs. This one loop runs every time you click a link, and understanding it makes the rest of the web much easier to reason about.

Request: the browser asks using HTTP
Process: the server reads, runs code, and may query data
Response: a status code plus the page content
Verify: look for 200 OK in the Network tab

Key takeaways

Every web page follows the same cycle: request, process, response.
An HTTP request is a short text message; GET means fetch and Host names the site.
The server may run app code and query a database, or simply send a file.
A response starts with a three-digit status code, then the page content.
The Network tab in your browser shows every request; 200 OK means success.
A 404 usually means a wrong address; a 500 means a problem on the server.

Frequently asked questions

What is the difference between a client and a server?

The client is the side that asks, which on the web is usually your browser. The server is another computer that receives the request and sends back an answer.

What does GET mean in an HTTP request?

GET is the HTTP method that means fetch. It is the most common method and is used every time you simply open a page, while other methods such as POST are used for jobs like sending a form.

Does a server always use a database?

No. A server queries a database only when the page needs stored information, such as your name and photo on a profile page. A simple page can be sent straight from a file.

How can I see HTTP requests in my browser?

Open developer tools with F12 or by right-clicking and choosing Inspect, then go to the Network tab and reload the page. Each row is one request, and clicking it shows the request and response headers.

What is the difference between a 404 and a 500 error?

A 404 means the page was not found, which usually points to a wrong or mistyped address. A 500 means something broke on the server while processing the request, so the server logs are the place to look.

Why does the Network tab show so many requests for one page?

After the browser receives the HTML, it sends more requests for images and style files. Each of those goes through its own request and response, so many rows is normal.

Watch the full video on YouTube →

Tag

Ad