How the Web Works

Understand the journey your browser takes to load a web page, from typing a URL to seeing the rendered result.

Before writing HTML, it helps to understand what happens behind the scenes: how a browser finds a website, requests its files, and turns them into the page you see.

Client and server

The web works on a client-server model. The client is your browser (Chrome, Firefox, Safari, etc.) — the program that asks for information and displays it. The server is a computer, usually far away, that stores website files and sends them out when asked.

Every time you visit a website, your browser (the client) sends a request to a server, and the server sends back a response. This request/response exchange is the foundation of how the web works.

URLs and DNS

A URL (Uniform Resource Locator), like https://www.example.com/courses, is the address you give the browser to tell it what you want to load. It identifies the protocol, the domain name, and often a specific path on that server.

Computers don't actually use domain names like "example.com" to locate each other on the internet — they use numeric IP addresses. DNS (Domain Name System) is the internet's directory service that translates a human-readable domain name into the numeric IP address of the server hosting that site. This step, called DNS resolution, happens automatically before the browser can even send its request.

HTTP/HTTPS and the request-response cycle

Once the browser knows the server's IP address, it communicates using HTTP (HyperText Transfer Protocol) — the set of rules that defines how requests and responses are formatted and exchanged. HTTPS is the secure, encrypted version of HTTP (the "S" stands for Secure), and virtually all modern websites use it to protect data in transit.

The browser sends an HTTP request asking for a specific resource (for example, the page at /courses). The server processes that request and sends back an HTTP response, which includes a status code (like 200 for success or 404 for not found) and, usually, the requested file's contents.

From response to rendered page

The first response for a normal page is typically an HTML document. But that HTML often references other resources — CSS stylesheets, JavaScript files, images, fonts. As the browser parses the HTML and encounters these references (like <link>, <script>, and <img> tags), it fires off additional requests to fetch each one.

Once the browser has the HTML (parsed into the DOM), the CSS (parsed into style rules), and any JavaScript has run, it combines all of this to calculate the layout and paint pixels on the screen — this final step is called rendering. This is why a page can appear to load in stages: text often appears before images, and styling can "pop in" as CSS finishes loading.

Anatomy of a URL

scheme — the protocol used (http or https) domain — the human-readable address resolved by DNS to an IP address path — the specific resource on the server being requested query string — optional extra parameters sent to the server

https://www.example.com/courses/html?level=beginner
\___/   \_______________/\_________________/\______________/
 scheme       domain            path            query string

Code Examples

This is a simplified example of what an HTTP request looks like — the browser is asking the server for the file index.html using the GET method. Expected result: The server locates index.html and prepares an HTTP response to send back.

"GET" is the HTTP method meaning "please give me this resource" (as opposed to, say, "POST", which submits data to the server).

This represents a simplified HTTP response: a status line, headers describing the content, and the actual HTML content. Expected result: The browser receives this response and begins parsing the HTML body into the DOM. The Content-Type header tells the browser how to interpret the data that follows — here, as HTML.

"200 OK" is a status code confirming the request succeeded; a missing page would return "404 Not Found" instead.

GET /index.html HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>
<html>...</html>

The request-response cycle

Loading a single web page usually involves multiple request/response round trips, not just one.

User types URL
      |
      v
  Browser ---(DNS lookup: domain -> IP)---> 
      |
      v (HTTP/HTTPS Request)
  Web Server
      |
      v (HTTP/HTTPS Response: HTML)
  Browser parses HTML
      |
      v (requests CSS, JS, images found in HTML)
  Web Server
      |
      v (responses: CSS/JS/image files)
  Browser renders final Web Page

Important Rules

The web uses a client-server model: browsers (clients) request resources, servers respond with them.

DNS translates human-readable domain names into numeric IP addresses.

HTTP defines the request/response format; HTTPS is the encrypted, secure version and should always be preferred.

An HTML page often triggers additional requests for CSS, JavaScript, images, and fonts referenced inside it.

Rendering is the final step where the browser combines the DOM, CSS rules, and JavaScript effects into pixels on screen.

Where this shows up

When your browser shows a spinning loading icon or slowly displays a page piece by piece, you are watching the request-response cycle happen in real time — DNS lookup, the initial HTML request, then a cascade of follow-up requests for CSS, JavaScript, and images before the page fully renders.

"The whole web page arrives in a single file and response." A page's HTML arrives first, then triggers separate requests for CSS, JS, images, and other assets.

Treating page load as one atomic transfer ignores how the browser incrementally discovers and fetches additional resources referenced inside the HTML.

"HTTPS and HTTP are basically the same thing, so it doesn't matter which one a site uses."

HTTPS encrypts the data exchanged between browser and server, protecting it from interception; it should be used whenever possible.

Confusing HTTP and HTTPS overlooks a critical security difference — HTTPS protects passwords, form data, and other sensitive information in transit.

[Predict the Output] A browser requests a page and the server responds with a status line reading "HTTP/1.1 404 Not Found". What does this tell the browser? A. The request succeeded and the HTML content follows normally. B. The requested resource could not be found on the server. C. The DNS lookup for the domain failed before any request was sent. D. The connection is encrypted and safe to display.

B. The requested resource could not be found on the server. — A 404 status code specifically means "Not Found" — the server understood the request but has no resource matching what was asked for. 200 would indicate success, and DNS failures happen before an HTTP status code is ever returned.

List, in the correct order, the major steps that happen between typing a URL into your browser and seeing a fully rendered page.

1. Browser resolves the domain name to an IP address via DNS. 2. Browser sends an HTTP/HTTPS request to the server. 3. Server sends back an HTML response. 4. Browser parses the HTML and finds references to CSS/JS/images. 5. Browser sends additional requests for those resources. 6. Browser combines everything and renders the final page.

Think about DNS, requests, responses, and additional resources like CSS and images.