How the web works provides a high-level description of what happens when you use a web browser to navigate to a web page, explaining the magic that goes on behind the scenes to deliver the relevant code to your computer for the browser to assemble into something you can look at.

This theory is not essential to writing web code in the short term, but before long, you'll really start to benefit from understanding what's happening in the background.

Note: This article does not cover how web browsers actually render code into web pages. That's covered in How browsers load websites.

Prerequisites:	Basic familiarity with your computer operating system, web browsers, and web technologies.
Learning outcomes:	Clients and servers and their roles in the web.DNS and how it works, at a high level.The purpose of TCP/IP, HTTP, and packets.HTTP syntax at a basic level.Common HTTP response codes (e.g., 200, 301, 403, 404, and 500).Basic components of a URL (protocol, domain, subdomain, path).

In this article

Clients and servers

Computers connected to the internet are called clients and servers. A simplified diagram of how they interact might look like this:

Two circles representing client and server. An arrow labeled request is going from client to server, and an arrow labeled responses is going from server to client

Clients are the typical web user's internet-connected devices (for example, your computer connected to your Wi-Fi, or your phone connected to your mobile network) and web-accessing software available on those devices (usually a web browser like Firefox or Chrome).
Servers are computers that store webpages, sites, or apps. When a client wants to access a webpage, a copy of the webpage code is downloaded from the server to the client machine, where it is rendered by the browser and displayed to the user.

The following embedded content from ScrimbaMDN learning partner provides further information on clients and servers, including a quiz and discussion.

The other parts of the toolbox

The client and server we've described above don't tell the whole story. There are many other parts involved, and we'll describe them below.

For now, let's imagine that the internet is a road. On one end of the road is the client, which is like your house. On the other end of the road is the server, which is like a shop you want to buy something from.

A black-and-white photo of a person crossing a road at a crosswalk

For data to get back and forth, we need the following things:

Your internet connection: Allows you to send and receive data on the internet. It's basically like the street between your house and the shop.
TCP/IP: Transmission Control Protocol and Internet Protocol (TCP/IP) are communication protocols that define how data should travel across the internet. This is like the transport mechanisms that let you place an order, go to the shop, and buy your goods. In our example, this is like a car or a bike (or however else you might travel along the road).
DNS: The Domain Name System (DNS) is like an address book for websites. When you type a web address in your browser, the browser looks at the DNS to find the website's IP address — the actual address the server is located at — before it can retrieve the website (see DNS explained below for more information). The browser needs to find out which server the website lives on, so it can send HTTP messages to the right place (see below). This is like looking up the address of the shop before you visit it.
HTTP: Hypertext Transfer Protocol (HTTP) is an application protocol that defines a language for clients and servers to speak to each other. This is like the language you use to order your goods. See HTTP basics below.
Files: A website is made up of many different files, which are like the different goods you buy from the shop. These files come in two main types:
- Code: Websites are built primarily from HTML, CSS, and JavaScript — the different programming languages websites are written in, which the browser interprets and assembles into a web page to display to a user.
- Assets: This is a collective term for all the other items that appear on a website — such as images, music, video, Word documents, and PDFs — that aren't code that the browser interprets.
Note: You can find out how the browser assembles these files into a web page later in the course, in How browsers load websites.

So what happens, exactly?

When you type a web address (which is technically part of a URL) into your browser address bar, the following steps occur:

The browser goes to the DNS server and finds the real address of the server that the website lives on.
The browser sends an HTTP request message to the server, asking it to send a copy of the website to the client. This message, and all other data sent between the client and the server, is sent across your internet connection using TCP/IP.
If the server approves the client's request, the server sends the client a "200 OK" message, which means "Of course you can look at that website! Here it is", and then starts sending the website's files to the browser as a series of small chunks called packets.
The browser assembles the small chunks into a complete web page and displays it to you.

DNS explained

Real web addresses (URLs) aren't the nice, memorable strings you type into your address bar to find your favorite websites. They are special numbers that look like this: 192.0.2.172.

This is called an IP address, and it represents a unique location on the web. However, it's not very easy to remember, is it? That's why the Domain Name System was invented. This system uses special servers that match up a web address you type into your browser (like mozilla.org) to the website's real (IP) address. Large websites are commonly made available on multiple servers, so that they load efficiently for different users worldwide. As a result, the IP address may vary depending on where you are.

You can use a DNS lookup tool to find the IP addresses of a website. For example, go to the NsLookup.io DNS lookup tool, type in developer.mozilla.org, and press the button.

Packets explained

Earlier, we used the term "packets" to describe the format in which the data is transferred between the client and server. What do we mean here?

When data is sent across the web, it is sent in multiple small chunks called packets. Each packet contains:

A header, which includes details such as the server and client IP address, the packet number, the total number of packets in the transmission, and details of the protocols used in the transmission.
A payload, which contains the actual data sent in the packet.

There are multiple reasons why data is sent in small packets, but most significantly:

They are sometimes dropped or corrupted, and when this happens, it's quicker and easier for the client to request the missing packets rather than an entire file.
The packets can be routed along different paths, making the transmission as efficient as possible and reducing the possibility of slowing down the network — especially when many users are requesting the same resource simultaneously. The packets may arrive out of sequence, but the client can use the information in the packet headers to make sure they are assembled in the correct order.

HTTP basics

HTTP uses a simple language of verbs to perform actions such as making requests (see HTTP request methods). The HTTP GET method is the one normally used to make HTTP requests of the type described above. For example, a request for the MDN home page might look like this:

GET /en-US/ HTTP/2

Host: developer.mozilla.org

The response sent by the server might look something like this:

HTTP/2 200

date: Tue, 11 Feb 2025 11:13:30 GMT
expires: Tue, 11 Feb 2025 11:40:01 GMT
server: Google frontend
last-modified: Tue, 11 Feb 2025 00:49:32 GMT
ETag: "65f26b7f6463e2347f4e5a7a2adcee54"
content-length: 45227
content-type: text/html

<!doctype html> ... (the 45227 bytes of the requested web page HTML)

The full response is more complex than this, but we have omitted most of it for brevity. The main parts are as follows:

HTTP/2 200

The version of HTTP that the server is using to send the response, in this case HTTP/2, followed by a status code indicating whether the request was successful. 200 indicates success.

date, expires, etc.

HTTP headers containing additional information about the response (note that requests can have headers too), which provide extra information and/or modify its behavior.

<!doctype html>, etc.

The response body, which in this case contains the MDN homepage's HTML document.

Note: See the MDN HTTP reference for a lot more detail on HTTP, if you are curious. An overview of HTTP is a good place to start.

Other status codes

Above, we met the 200 status code, which indicates that the HTTP request was successful. There are many HTTP status codes with specific meanings and uses, but you will only commonly see a few:

`301`

The requested resource has been permanently moved to a new location, which is provided in the response. This is used for redirecting content when it's moved.

`400`

The server can't process the request. This usually happens when the request isn't in a format the server understands, or has errors in it.

`403`

The server will not give the client access to the requested resource. This usually happens when the server knows who the client is, but they don't have permission to access the requested page.

`404`

The server cannot find the requested resource. This status is commonly returned if the URL is wrong or if content is deleted without putting a redirect in place.

503

The request cannot be handled due to a problem with the server. This is common when servers are offline for maintenance, and it's expected to be temporary.

Components of a URL

Technically, web addresses that you type into the browser address bar form part of Uniform Resource Locators (URLs). URLs define the locations of unique resources on the internet.

A URL is a web address plus a protocol: for example, if you open a new tab in your browser, type in developer.mozilla.org into the address bar, and press Enter/Return, you will be redirected to a URL like the following one:

https://developer.mozilla.org/en-US/

The main parts of the URL are:

https

The protocol being used to send the request. In this case, we are using HTTPS, which is a secure version of HTTP that stops bad people from reading your data while it is being transported. On the modern web, pretty much every server uses HTTPS, so if you don't include it explicitly, the browser assumes that is what you are using and adds it for you.

developer.mozilla.org

The domain name of the URL, which represents the top-level location of the server you are connecting to. In this case, the web address you typed in is equal to the domain name, but this is not always the case — you could choose to type in a more complicated web address. Note that the developer part is a subdomain (distinct content area) of Mozilla's mozilla.org domain. There are other subdomains on Mozilla's site that host distinct content — see support.mozilla.org and bugzilla.mozilla.org, for example.

/en-US/

The path to the resource on the server that you are accessing. MDN keeps all its US English content in a folder called en-US, which is what this URL is pointing to.

If you have your browser set up to prefer English content by default, then this is the URL you will be redirected to when you type in developer.mozilla.org. If you have your browser set up to prefer a different language that MDN supports, such as French, you will be redirected to a different URL, such as https://developer.mozilla.org/fr/ instead. This isn't available to every website by default; the MDN developers have set MDN up like this to allow people to easily access the language they prefer.

How the web works

Presentation