JOVANA
Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

How the Web Works

Press Enter, a page appears — here's the fast relay race that happens in between, explained from scratch.

The whole journey in one breath

You type an address into your browser and press Enter. A heartbeat later, a finished page is sitting in front of you — text, pictures, buttons, all in place. It feels like one instant thing, but it is really a tiny relay race between several players, each handing off to the next.

Here is the race in four legs: first your computer finds where the page lives, then it asks the right server for it, then the server answers, and finally your browser paints everything into the page you see. We'll walk each leg slowly, in plain words, and you'll never have to wonder what's happening behind that loading spinner again.

Step 1 — Finding the place

The address you typed — something like https://example.com/about — is called a URL. Think of it as a full postal address: it says which protocol to speak (the https:// part), which site you want (example.com), and which exact page on that site (/about). It's the where of the whole trip.

But the network doesn't actually understand names like example.com — it routes everything by number, the way the phone system needs a phone number, not just a person's name. So the first real job is a lookup: turning the name into a number. That's the job of the DNS, the internet's phone book. You give it example.com and it hands back an address like 93.184.216.34.

Step 2 — The conversation

Now your browser knows the server's number, so it can knock on the door and ask for the page. The language they speak is HTTP — basically a polite, structured way of saying 'please send me the page at /about.' Your browser sends a request; the server sends back a response. Question, then answer. That back-and-forth is the heart of the whole web.

Every response comes stamped with a status code — a three-digit number that says how it went. 200 means 'here you go, all good.' 404 means 'I looked, but there's no page by that name.' 500 means 'something broke on my end.' You'll learn to read these like a mood ring for the server.

GET /about HTTP/1.1
Host: example.com

--- the server replies ---
HTTP/1.1 200 OK
A request asking for /about, and a 200 OK reply meaning 'here's the page.'

You'll notice most addresses start with HTTPS, not plain HTTP — that extra S stands for secure. It wraps the whole conversation in a sealed envelope, so nobody sitting on the same coffee-shop wifi can read your password or swap the page out for a fake one. Plain HTTP is a postcard anyone can read; HTTPS is a locked envelope. Always prefer the locked one.

Step 3 — The server answers

So who actually receives that request? On the server machine there's a long-running program whose only job is to sit and wait for visitors. Often it's a daemon — a program that runs quietly in the background with no window, just listening. It waits at a numbered doorway called a port (the web's usual doorway is port 443 for HTTPS), the way an apartment building has one street address but many unit numbers.

For a simple page the server just hands back a file. But often the page needs live data — your order history, today's weather — so the server program calls an API, a clearly-labeled service-counter for data. You ask at a specific endpoint (a URL like /api/weather) and it usually answers in JSON, a tidy text format that both computers and humans can read.

{
  "city": "Taipei",
  "temp": 28,
  "sky": "clear"
}
A typical JSON answer from an API endpoint — labeled boxes of data, easy to read.

Step 4 — The browser builds the page

What comes back isn't a picture of a page — it's a recipe for one, and your browser is the cook. The recipe comes in three ingredients working together. HTML is the structure: the headings, paragraphs, and buttons, like the bare framing of a house. It says what's on the page, not yet how it looks.

CSS is the styling — colors, fonts, spacing, the paint and furniture that make the bare house look nice. JavaScript is the behavior — it makes things move and react: menus that open, a button that adds to your cart, content that updates without reloading. Your browser reads all three and assembles them into the living page in front of you.

Two things that confuse beginners

First, how does a site remember you between pages, so you don't have to log in again on every click? The answer is a cookie — a tiny note the server asks your browser to keep and show again on the next request. It usually just holds a meaningless ID that the server recognizes as 'oh, this is the same visitor as before.' That's how 'stay logged in' and your shopping cart survive from one page to the next.

Second, sometimes you'll see a scary red CORS error in the console when a page tries to fetch data from a different website than the one you're on. It's not a bug in your code so much as a safety rule: by default, the browser won't let site A quietly read data from site B unless site B has said 'yes, I allow that.' It feels annoying the first time, but it's there to stop a sketchy page from siphoning your data off another site you're logged into.

Recap — the relay race, end to end

That's the whole trip. None of it is magic — it's just four handoffs happening faster than you can blink, every single time you open a page. Once you can name the legs, the web stops being a mystery box and becomes something you can reason about, poke at, and eventually build.

  1. Find the place: the URL points the way, and DNS turns the name into a number.
  2. Have the conversation: the browser sends an HTTP/HTTPS request and gets a response with a status code.
  3. Get the answer: a server program listening on a port replies, sometimes pulling fresh data as JSON from an API endpoint.
  4. Build the page: the browser assembles HTML, CSS, and JavaScript into what you finally see.