How the Web Works

Knowing how a browser turns a URL into a visible page is one of the most useful mental models an engineer can have. It makes debugging faster, architecture decisions clearer, and conversations with teammates more precise.

Target reader: Anyone curious about what happens between pressing Enter and seeing a web page. Estimated time: 15 min read + 10 min hands-on Prerequisites: What Is the Internet? (recommended)

The Web vs the Internet

The Internet is the underlying infrastructure — cables, routers, IP addresses, and the TCP/IP protocols that connect devices globally.

The World Wide Web (WWW) is one application built on top of that infrastructure. It is the system of documents (web pages) linked together by hyperlinks and accessed using a protocol called HTTP.

An analogy: the Internet is the road network. The Web is one type of vehicle (web browsers) that runs on those roads. Other vehicles (email clients, SSH terminals, FTP tools) also use the same roads.

URL Anatomy

Every web resource has an address called a URL (Uniform Resource Locator). Breaking a URL into its parts makes it much easier to understand.

https://www.example.com:443/blog/post?id=42&lang=en#section2
  |        |           |   |         |              |
scheme   domain       port path     query string   fragment

Part	Example	Purpose
Scheme	`https`	Protocol to use (`http`, `https`, `ftp`, etc.)
Domain	`www.example.com`	Human-readable server address
Port	`:443`	Network port (443 is the default for HTTPS; usually omitted)
Path	`/blog/post`	Location of the resource on the server
Query string	`?id=42&lang=en`	Key-value parameters sent to the server
Fragment	`#section2`	In-page anchor (handled by the browser, not sent to the server)

A minimal URL needs only the scheme and domain: https://example.com.

What HTTP and HTTPS Are

HTTP (HyperText Transfer Protocol) is the set of rules that browsers and servers use to communicate. It is a request-response protocol: the browser sends a request, and the server sends back a response.

HTTPS is HTTP with an added security layer called TLS (Transport Layer Security). TLS encrypts the data so that:

Eavesdroppers on the network cannot read the content.
The browser can verify it is talking to the correct server (not an impostor).

In 2026, virtually all websites use HTTPS. Browsers mark plain HTTP connections as “Not Secure.”

HTTP Methods

HTTP requests include a method (also called a verb) that tells the server what action is being requested.

Method	Intuitive meaning	Common use
GET	”Give me this resource”	Loading a page, fetching an image
POST	”Here is data, do something with it”	Submitting a form, creating a record
PUT	”Replace this resource with new data”	Updating a user profile
DELETE	”Remove this resource”	Deleting a post

For beginners, GET and POST cover the vast majority of web interactions. GET requests have no body — the parameters go in the URL. POST requests carry data in the request body (e.g., the contents of a login form).

HTTP Status Codes

Every HTTP response includes a three-digit status code that summarizes the outcome.

Code	Category	Meaning	Common example
200	Success	OK — the request succeeded	Page loaded normally
301	Redirect	Moved Permanently — use a new URL	Old URL redirected to new one
400	Client Error	Bad Request — the request was malformed	Missing required field
401	Client Error	Unauthorized — authentication required	Not logged in
403	Client Error	Forbidden — no permission	Accessing another user’s data
404	Client Error	Not Found — resource does not exist	Broken link
500	Server Error	Internal Server Error — something went wrong on the server	Bug in server code

The first digit signals the category: 2xx success, 3xx redirect, 4xx client mistake, 5xx server mistake.

Step-by-Step: How a Browser Displays a Page

Here is the full journey when https://example.com/about is entered in the address bar:

Browser                   DNS Resolver            Server
  |                            |                     |
  |-- "What IP is example.com?" -->                  |
  |                            |-- query root DNS    |
  |                            |-- query TLD DNS     |
  |                            |-- query authoritative DNS
  |<-- "IP: 93.184.216.34" ---|                     |
  |                                                  |
  |------------- TCP 3-way handshake -------------->|
  |<------------ Connection established ------------|
  |                                                  |
  |------- TLS handshake (HTTPS only) ------------>|
  |<------ Encrypted channel established ----------|
  |                                                  |
  |-- GET /about HTTP/1.1 ------------------------->|
  |   Host: example.com                             |
  |                                                  |
  |<-- HTTP/1.1 200 OK -----------------------------|
  |   Content-Type: text/html                       |
  |   [HTML body]                                   |
  |                                                  |
  | [Parse HTML → fetch CSS, JS, images]            |
  | [Render page]                                   |

Step 1: DNS Resolution

The browser does not know the IP address of example.com. It asks a DNS resolver (usually provided by the internet service provider or configured manually) to look it up. The result — for example, 93.184.216.34 — is cached for a period defined by the domain’s TTL (Time to Live).

Step 2: TCP Connection

The browser opens a TCP connection to the server’s IP address on port 443 (HTTPS). This involves a three-step handshake: SYN → SYN-ACK → ACK.

Step 3: TLS Handshake (for HTTPS)

The browser and server negotiate encryption keys. The server presents a certificate that proves its identity. After the handshake, all data is encrypted.

Step 4: HTTP Request

The browser sends an HTTP GET request:

GET /about HTTP/1.1
Host: example.com
Accept: text/html
User-Agent: Mozilla/5.0 ...

Step 5: HTTP Response

The server processes the request and responds:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 4823

<!DOCTYPE html>
<html>
  <head>...</head>
  <body>...</body>
</html>

Step 6: HTML Parsing and Rendering

The browser parses the HTML and builds a DOM (Document Object Model) — a tree structure representing the page. As it encounters <link> tags (CSS) and <script> tags (JavaScript), it sends additional HTTP requests to fetch those resources. Once everything is loaded, the browser paints the page on screen.

Hands-On: Inspecting HTTP in the Browser

Every modern browser has developer tools that make the HTTP exchange visible.

Open any web page.
Press F12 (or Cmd+Option+I on macOS) to open developer tools.
Click the Network tab.
Reload the page.
Click on any request to see its method, status code, headers, and response body.

This is one of the most useful debugging tools available, and it is built into the browser.

Summary

The Web is a system of linked documents accessed via HTTP/HTTPS, built on top of the Internet.
A URL has six components: scheme, domain, port, path, query string, and fragment.
HTTP is a request-response protocol. The most common methods are GET and POST.
Status codes indicate outcomes: 200 OK, 404 Not Found, 500 Server Error.
Loading a page involves DNS resolution → TCP connection → TLS handshake → HTTP request → HTTP response → HTML parsing → rendering.

FAQ

Q: What is the difference between HTTP and HTTPS?

A: HTTP sends data in plain text, which anyone on the network path can read. HTTPS wraps HTTP in TLS encryption, protecting both the content and the identity of the server. All sites should use HTTPS today.

Q: Why does a URL sometimes have www. and sometimes not?

A: www is a subdomain — it is just a convention. Technically, www.example.com and example.com are different hostnames, though most sites configure them to serve the same content. DNS and server configuration determine which form (or both) works for a given site.

Q: What is the difference between a GET request and a POST request?

A: A GET request retrieves a resource and should not change server state. A POST request submits data and typically causes a change (creating a record, triggering an action). GET parameters appear in the URL; POST data is sent in the request body and is not visible in the URL.

Q: What causes a 500 error?

A: A 500 Internal Server Error means something went wrong on the server side — a bug in the application code, a database connection failure, or a configuration problem. It is always the server’s responsibility, not the user’s.

Next: Servers and Clients

Link to this page (Japanese): ウェブの仕組み