Then you press refresh on that page and get a 404. Or you send the link to a colleague and it fails for them. Or a user opens a bookmark and lands on your hosting provider's error page instead of your app.

Nothing in your routing code is wrong. The route exists, the component is correct, and the router is configured properly. The problem is that on a refresh, your router is not the thing answering the question. It has not even loaded yet.

Why does the same URL work when I click but not when I reload?#

These are two completely different journeys, and the difference is the whole article.

When you click a link inside a single page application, no request goes out. Your Javascript intercepts the click, calls the History API to change what the address bar displays, and swaps the component on screen. The URL changes, but the browser never asks anyone for anything. The page you were already on simply redraws itself.

When you press refresh, the browser throws all of that away and does what it always does with a URL, which is ask the server for it. It sends a real GET /settings over the network, and now your application is not involved at all, because it no longer exists. It was wiped from memory the moment you hit reload.

So the server receives a request for /settings, looks in the folder it is serving, and finds index.html, a assets directory and nothing else. There is no settings file and no settings folder, because your build never created one. It responds with a 404, correctly, because from its point of view that path genuinely does not exist.

The route only ever existed inside Javascript that never got a chance to run.

Why is this not a bug in React Router?#

Because client side routing is, by design, a fiction that the browser maintains on your behalf.

pushState lets Javascript change the address bar without making a request. That is what makes an SPA feel fast, and it is the entire trick behind modern frontend frameworks. But the address bar is only a display. Changing it does not create anything on the server, does not register a path anywhere, and does not survive a reload.

Your router can only handle a URL if it is already running. On a refresh or a direct visit, the order is reversed: the request happens first, and your router loads afterwards, if the server sends it anything at all. Every framework has this problem, whether it is React Router, Vue Router, Angular, or a router you wrote yourself in an afternoon.

How do you actually fix it?#

There is one rule, and every fix below is the same rule written in a different configuration language:

When a request does not match a real file, send index.html anyway, with a 200 status.

That way, a request for /settings returns your application. The browser loads it, your router starts up, reads /settings from the address bar, and renders the right screen. The server does not need to know your routes. It just needs to hand over the app and let the app sort it out.

For Nginx:

location / {
  try_files $uri $uri/ /index.html;
}

That reads as "try the file, then the directory, then fall back to index.html".

For Apache, in .htaccess:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.html [L]

For an Express server hosting a build:

app.use(express.static("dist"));
app.get("*", (req, res) => {
  res.sendFile(path.join(__dirname, "dist", "index.html"));
});

The order matters here. The static middleware has to come first, otherwise the catch all swallows requests for your Javascript and CSS as well, and you will get an application that loads index.html for every asset it asks for.

Most hosting platforms have this built in or one line away. Netlify uses a _redirects file with /* /index.html 200. Vercel and Cloudflare Pages detect common frameworks and handle it automatically. On S3 with CloudFront, the usual approach is to set the error document to index.html, though it is worth noting that this historically returned a 403 or 404 status underneath, which search engines do notice.

Why does it work in development but break in production?#

Because your development server already does this for you, quietly.

Vite, webpack dev server and the Next.js dev server all have history API fallback turned on by default. They serve index.html for anything that does not match a file, precisely so that refreshing during development does not annoy you. Then you build, upload the dist folder to a plain static host, and the fallback disappears with it.

This is why the bug so reliably appears at the worst possible moment. It is not introduced by the build. It was hidden by the dev server the entire time you were working.

Why does the page load but every asset 404?#

This is the neighbouring bug, and people often meet it right after fixing the first one.

If you deploy your app into a subdirectory, such as example.com/app/, your index.html will ask for /assets/main.js starting from the domain root, and the server will not find it there. You get a blank white page, a console full of 404s, and often a MIME type error complaining that your Javascript was served as HTML. That error is the fallback doing its job, by the way. It returned index.html for a missing script, exactly as instructed.

The fix is to tell your build where it will live. In Vite that is the base option, in webpack it is publicPath, and in Next.js it is basePath. Set it to /app/ and the generated paths line up with reality.

What about pages that really are missing?#

Once every path returns index.html with a 200, your server can no longer produce a genuine 404. That is a real cost, and it is worth handling deliberately rather than ignoring.

Your router should have a catch all route that renders a proper "not found" screen, so a typo in the URL shows something sensible instead of a blank layout.

For search engines the situation is more awkward. A crawler asking for a mistyped or deleted URL receives a 200 and a page, which tells it the URL is valid. Enough of these and you have what is usually called a soft 404, where search engines index URLs that were never meant to exist. If those pages matter to you, the answer is server side rendering or prerendering for real routes, so that a missing one can return an honest 404 status. A client side catch all screen fixes the experience for people, but it cannot fix the status code, because by the time your Javascript decides the page is missing, the response has already been sent.

A checklist to work through#

1. Does refreshing on the home page work, but refreshing on a nested route fail? Then it is this, and the fix is in your host configuration, not your router.
2. Have you added a fallback that serves index.html for unmatched paths?
3. Does the fallback return 200, rather than a 404 page that happens to contain your app?
4. Is static file handling registered before the catch all, so assets are still served normally?
5. Are you deploying into a subdirectory? If yes, set base, publicPath or basePath to match.
6. Does your router have a catch all route for genuinely unknown URLs?
7. Does it work in npm run dev but not on the deployed build? That is the dev server's fallback hiding the problem.

Frequently asked questions#

Why does the home page refresh fine but nothing else?#

Because / maps to a file that genuinely exists. Your server finds index.html and serves it, so the app loads and the router takes over. Every other route has no matching file, so it fails at the server before your Javascript is ever involved.

Is hash routing a valid fix?#

It works, and it needs no server configuration at all, because everything after the # is never sent to the server. Your URLs become example.com/#/settings, and the server only ever sees a request for /. The tradeoff is ugly URLs and weaker SEO, since the fragment is not part of what gets requested. It is a reasonable choice for an internal tool or an app behind a login, and a poor one for anything you want indexed.

Does this affect server side rendered apps?#

No, and that is one of the reasons frameworks moved back towards rendering on the server. With Next.js, Nuxt or SvelteKit in their default modes, the server knows your routes and can answer a request for /settings with real HTML, including a real 404 when the page does not exist. You only meet this problem when you export a purely static build and hand it to a server that knows nothing about your routing.

Why do I get a MIME type error about my Javascript?#

Almost always because the fallback returned index.html for a missing asset. The browser asked for a script, received HTML, and refused to execute it. Fix the asset path rather than the fallback, since the fallback is behaving correctly.

Should the fallback return 200 or 404?#

200, for any route your application actually handles. A 404 status tells the browser and search engines the page does not exist, even if you send your app alongside it. Reserve genuine 404 responses for URLs that really are gone, which in practice means rendering on the server.

Related reading#

• Why we needed Single Page Applications (SPAs)
• What happens after you press Enter
• What is a server? Types, Hardware, Software and the Cloud
• Why we needed React

The natural conclusion is that something is wrong with your fetch code. Usually there is nothing wrong with your fetch code. The request is fine, and the server is fine. What changed is who is making the request.

Postman is not a browser. It is a program that opens a connection and sends bytes. A browser is a program that opens a connection, sends bytes, and then enforces a long list of rules designed to protect the user from the website they are currently visiting. Those rules do not exist in Postman, so Postman can never tell you whether a browser would have allowed the same call.

What is Postman actually skipping?#

Three things, and each one causes a different failure.

The first is the origin. Every request a browser makes comes from a page, and that page has an origin made of scheme, host and port. https://app.example.com and https://api.example.com are different origins, and so are http://localhost:3000 and http://localhost:5173. Postman has no origin at all, because it is not on a page. So it can never be making a cross origin request, which means the whole set of cross origin rules simply does not apply to it.

The second is cookie handling. Postman keeps a cookie jar that ignores SameSite, ignores Secure, and cheerfully stores things a browser would throw away. I wrote about that in detail in why your cookie is not being set, and it is the second most common cause of this exact symptom.

The third is the same origin policy, which is the rule underneath all of it. A page is not allowed to read the response from another origin unless that origin explicitly agrees. Without this, any website you visited could quietly read your email, because your browser would happily attach your cookies to a request to your mail provider and hand the result to whatever script asked for it.

So when Postman succeeds and the browser fails, the browser is usually not broken. It is doing the one job Postman was never asked to do.

Is it a CORS error?#

Open the console and look for wording like this:

Access to fetch at 'https://api.example.com/users' from origin
'http://localhost:3000' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

If you see that, the server never gave the browser permission to share the response with your page. The fix is on the server, which has to say who is allowed:

Access-Control-Allow-Origin: http://localhost:3000

There is one detail here that saves a lot of confusion. CORS is enforced by the browser, not by the server. The server does not block anything. It simply states, in a response header, which origins are allowed to read what it sent. The browser reads that statement and decides whether to hand the response to your JavaScript or throw it away.

This is why adding a CORS library to your backend feels like it "unlocks" the API. Nothing was locked. You just started answering a question the browser had been asking all along.

Why is there an OPTIONS request I never wrote?#

Look at the Network tab and you will often find an OPTIONS request sitting in front of your real one, which nobody in your codebase asked for. That is a preflight.

Before sending certain cross origin requests, the browser sends a small OPTIONS request to ask whether the real one is acceptable. It does this whenever the request is not what the specification calls simple, which in practice means any of the following:

• The method is something other than GET, HEAD or POST.
• You set a custom header, such as Authorization or X-Api-Key.
• The Content-Type is anything other than application/x-www-form-urlencoded, multipart/form-data or text/plain.

That last one catches almost everybody, because application/json is not on the list. A perfectly ordinary JSON POST is preflighted, which is why so many people meet OPTIONS for the first time while debugging their login form.

The preflight asks its question with headers, and the server has to answer all of them:

Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

If the preflight fails, the real request is never sent at all. This produces one of the strangest symptoms in web development, where your backend logs show nothing, your endpoint is definitely running, and the browser insists it tried. It did try. It asked permission first, did not like the answer, and stopped.

Access-Control-Max-Age is worth setting, because it tells the browser how long it may reuse the answer instead of preflighting every single call.

Why does the preflight come back 401 or 403?#

This one deserves its own section, because the cause is almost always the same and it is very easy to miss.

An OPTIONS preflight is sent without credentials. No cookies, no Authorization header, nothing. It is a question about permission, not an attempt to do anything. If your authentication middleware runs before your CORS middleware, it sees a request with no credentials attached and rejects it with a 401, long before anything gets a chance to answer the browser's question.

The result looks like a broken login, but the login was never attempted. The fix is ordering. CORS handling has to come first in your middleware chain, and the OPTIONS method has to be allowed through without authentication.

Why does the response arrive but my code still fails?#

Sometimes the Network tab shows a healthy 200 with a full response body, and your fetch still rejects. Reading that as a contradiction is understandable, but both things are true at once.

Unless a request is preflighted, the browser sends it, the server receives it, and it does whatever it was going to do. The row you are looking at in the Network tab is real. What the browser then does is check the CORS headers on the way back, decide your page is not allowed to read the result, and reject the promise with a TypeError and no status code.

The important consequence is one that catches people out on the security side. A blocked response does not mean a blocked request. If that call created a record or charged a card, that still happened. CORS protects the user from reading data, and it was never a substitute for the server checking whether the caller was allowed to act. It is the same principle as the fact that a server can never trust your browser, just seen from the other direction.

If you need to read a custom response header, note that the browser hides those too. The server has to list them explicitly with Access-Control-Expose-Headers, which is why your pagination or rate limit header looks missing even though you can see it in the Network tab.

Why does it break only when I send cookies?#

The moment your request carries credentials, the rules get stricter.

First, you have to opt in on the client, because fetch does not send cookies cross origin by default:

await fetch("https://api.example.com/me", { credentials: "include" });

Then the server has to opt in as well, with one extra rule that surprises everybody:

Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Credentials: true

Access-Control-Allow-Origin: * is not allowed once credentials are involved. The wildcard means "anyone may read this", and the browser refuses to combine that with a request carrying somebody's session. You have to name the exact origin, which usually means reading the incoming Origin header and echoing it back from a list you trust. If you do that, send Vary: Origin too, otherwise a cache can serve one origin's response to another.

And if the cookie itself is the problem rather than the CORS configuration, the request will look permitted while the user stays logged out. That is a different bug with its own checklist, and the quickest way to tell them apart is whether the console shows a CORS message at all. No message and no session usually means the cookie never made it.

A checklist to work through#

Go in this order, because each step rules out the one after it:

1. Does the console show a CORS message? If not, it is probably a cookie or session problem, not a CORS one.
2. Is there an OPTIONS request in the Network tab, and what did it return? Fix that before looking at anything else.
3. If the preflight returned 401 or 403, move your CORS middleware above your auth middleware.
4. Does the response carry Access-Control-Allow-Origin, and does it match your origin exactly, including scheme and port?
5. Are you sending credentials? Then the wildcard is out and Access-Control-Allow-Credentials: true is required.
6. Are you trying to read a custom header? Add Access-Control-Expose-Headers.
7. Are your frontend and backend using the same hostname spelling, rather than mixing localhost and 127.0.0.1?

Frequently asked questions#

Can I fix CORS from the frontend?#

No, and this is worth being blunt about. The permission has to come from the server that owns the data, because the entire point is that a page cannot grant itself access to another origin. Browser extensions that disable the check only change your own machine, and your users will still be blocked.

Is a proxy a legitimate fix?#

Yes, and it is the standard answer when you do not control the API. Your own backend calls the third party server to server, where none of these rules apply, and your frontend talks only to your backend on the same origin. Most dev servers, including Vite and Next.js, have a proxy option built in for exactly this during development.

Why does it work in production but not locally?#

In production your app and API are often served from the same origin, or from a properly configured one, so no cross origin rules apply. Locally they sit on two different ports, which makes them two different origins. Anything marked Secure also disappears over plain HTTP, which is why local development finds these bugs first.

Does a CORS error mean my API is secure?#

Not at all. CORS only stops other websites from reading responses in a user's browser. It does nothing about direct calls, which is precisely why Postman reached your endpoint without any difficulty. If an endpoint should be restricted, the server has to check that itself on every request.

Why does Postman succeed when the browser fails?#

Because Postman has no origin, does not apply the same origin policy, never sends a preflight, and ignores cookie attributes. A green result in Postman proves your server works. It proves nothing about whether a browser will let your page read the answer.

Related reading#

• Why your cookie is not being set
• Why a server can never trust your browser
• Seven HTTP request headers every developer should understand
• What is a server? Types, Hardware, Software and the Cloud

The frustrating part is that nothing failed. There is no error in the console, no warning in the terminal, no rejected promise. The browser received the cookie, looked at it, decided it was not allowed to keep it, and threw it away without telling anyone.

That silence is intentional. A cookie is storage that a website asks the browser to hold on its behalf, and the browser decides whether the request is acceptable. When it says no, it just says nothing.

There are only a handful of reasons this happens. Once you know them, this stops being a mystery and becomes a checklist.

First, find out where the cookie is actually being lost#

Before changing any code, you need to answer one question: did the server never send the cookie, or did the browser refuse to store it? These are completely different problems, and people waste hours fixing the wrong one.

Open the Network tab, click the request that should be setting the cookie, and look at the response headers. You are looking for a line like this:

Set-Cookie: sessionId=abc123xyz; HttpOnly; Path=/; SameSite=Lax

If that header is not there, the problem is in your backend. Your server never asked for anything to be stored, so the browser has nothing to reject. Go and check your session middleware, your response code, or whether that branch of your login handler is even running.

If the header is there but the Application tab is still empty, the browser received the instruction and rejected it. Everything below is about that second case.

Browsers usually help you here. In Chrome, the Network tab shows a small warning icon next to a blocked cookie, and hovering over it tells you which rule was broken. Look there before you start guessing.

Is SameSite blocking a cross-site cookie?#

This is the most common cause today, and it became common because the default changed.

SameSite controls whether a cookie is attached to requests that come from a different site. If you do not set it at all, browsers now treat the cookie as SameSite=Lax. That means the cookie is sent on normal top level navigation, like clicking a link, but it is not sent on cross site requests made in the background by JavaScript.

So if your frontend runs on app.example.com and your API runs on api.otherdomain.com, a Lax cookie will not travel between them. Your login request succeeds, the cookie comes back, and it is either dropped or never sent again afterwards.

The fix is to say explicitly that the cookie is allowed to cross sites:

Set-Cookie: sessionId=abc123xyz; HttpOnly; Secure; SameSite=None

There is one rule that catches everybody: SameSite=None is only accepted together with Secure. If you send SameSite=None without Secure, the browser rejects the whole cookie. Not the attribute, the entire cookie. And Secure means HTTPS, which is why this often works in production and fails on your machine.

The restriction is worth understanding rather than working around. A cookie that travels on every cross site request is what made CSRF attacks easy for years, so the browser is refusing to hand your session to a site that did not earn it. It is the same instinct behind the fact that a server can never trust your browser.

Are you actually sending credentials with the request?#

A cookie can be stored correctly and still never leave the browser again.

By default, fetch does not send cookies to a different origin, and it does not store cookies that come back from one either. You have to ask for it:

await fetch("https://api.example.com/login", {
  method: "POST",
  credentials: "include",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ email, password }),
});

In axios the equivalent is withCredentials: true. If you use a generated API client, check whether it exposes this option, because many do not send credentials unless you configure it.

The server has to agree as well. For a cross origin request with credentials, it must respond with Access-Control-Allow-Credentials: true, and Access-Control-Allow-Origin must name your exact origin. The wildcard * is not allowed once credentials are involved.

Both sides need to opt in, and this is the part that most often looks like a cookie problem when it is really a configuration problem.

Is Secure set while you are on an http page?#

The Secure attribute tells the browser to only store and send the cookie over HTTPS. On an http:// page, a cookie with Secure is dropped immediately.

This produces a confusing symptom: everything works in production and nothing works locally. Production is on HTTPS, your development server is on plain HTTP, and the same code behaves differently in each place.

Browsers do make an exception for localhost, which counts as a secure context even over HTTP. That exception is narrower than people expect though, and it does not cover a local network address like 192.168.1.40 or a custom hostname from your hosts file. If you test on your phone over the local network, this is very often the reason.

Does the Domain attribute match the site you are on?#

A cookie can only be set for the domain the response came from, or for a parent of it. A server on api.example.com can set a cookie for example.com, because that is its parent. It cannot set one for otherdomain.com, and if it tries, the browser discards the cookie.

The rules also work differently depending on whether you include the attribute at all:

Set-Cookie: sessionId=abc; Domain=example.com

That cookie is available on example.com and on every subdomain, including app.example.com and api.example.com.

Set-Cookie: sessionId=abc

That one, with no Domain, is only available on the exact host that set it. This is the mistake behind "the cookie exists but my subdomain cannot see it". Nothing is broken, the cookie was simply never shared in the first place.

Does the Path match the page you are looking at?#

Path limits the cookie to one section of the site. A cookie set with Path=/admin is not sent when you request /dashboard, and it will not appear in the Application tab while you are looking at a page outside that path.

Some session libraries set a narrow path by default, or inherit it from the route that created the session. If your cookie appears on one page and vanishes on another, check this before anything else. In almost every case you want Path=/.

Why localhost makes all of this worse#

localhost and 127.0.0.1 are two different hosts as far as cookies are concerned, even though they reach the same machine. A cookie set on one is invisible to the other. If your frontend calls http://localhost:3000 while your browser is open on http://127.0.0.1:3000, you will see exactly the symptoms described in this article.

Ports, on the other hand, are ignored. Cookies do not isolate by port, so localhost:3000 and localhost:5173 share the same cookie jar. That surprises people in the opposite direction, because a stale cookie from another project can quietly interfere with the one you are debugging.

The practical rule is to pick one hostname and use it everywhere, in your browser, in your API base URL, and in your environment files.

A checklist to work through#

When a cookie is missing, go through these in order:

1. Is the Set-Cookie header present in the response? If not, the problem is in your backend.
2. Does the browser show a warning icon next to that header? Read it first.
3. Is the request cross site? If yes, you need SameSite=None; Secure and HTTPS.
4. Is credentials: "include" set on the request, and does the server allow credentials with an explicit origin?
5. Is Secure set while you are browsing over plain HTTP?
6. Do the Domain and Path attributes cover the page you are testing on?
7. Are you consistently on either localhost or 127.0.0.1, and not mixing the two?

Most missing cookie bugs are one of these seven, and they are usually found in under a minute once you start at the top instead of guessing.

Frequently asked questions#

Why does my cookie work in Postman but not in the browser?#

Postman does not enforce SameSite, and it ignores the browser rules about cross origin requests and credentials. It stores whatever you tell it to. A cookie working in Postman only proves your server sends the header correctly, and tells you nothing about whether a browser would accept it.

Why can I not see my cookie in JavaScript?#

If the cookie was set with HttpOnly, document.cookie cannot read it, by design. The cookie is still there and it is still sent with every matching request, but scripts on the page are locked out of it. This is deliberate protection for login sessions, because it means a script injected into your page cannot steal the session identifier.

Why does my cookie disappear when I close the browser?#

That is a session cookie, which is any cookie set without Expires or Max-Age. The browser is doing exactly what it was asked. If you want the cookie to survive a restart, add a Max-Age in seconds.

Does a missing cookie mean the session was never created?#

Not necessarily. The server may have created the session record and stored it perfectly well, and only the identifier failed to reach the browser. The record and the cookie are two separate things, which is easier to see once you understand how sessions and tokens differ.

Why did this start failing without any code change?#

Browsers tightened cookie defaults over several releases, and the change to treat unspecified cookies as SameSite=Lax broke a large number of working integrations. If a cookie stopped being stored after a browser update, and the cookie crosses sites, that default is the first thing to check.

Related reading#

• Why your API works in Postman but not in the browser
• Cookies vs Sessions vs Tokens: How websites keep you logged in
• Session vs session cookie vs sessionStorage
• Why a server can never trust your browser
• Seven HTTP request headers every developer should understand

One of them is data sitting on a server. Another one is a rule about when a cookie is deleted. The third one is a small box of text that belongs to a single browser tab and that the server never sees.

They share a word, and that's it. They live in different places, different code can read them, and completely different events end them. Once you separate the three, a whole category of confusing bugs stops being confusing.

The server session: data that never leaves the server#

A server session is information the server stores about you between requests. After you log in, the server writes down who you are, when you authenticated, maybe your permissions, and keeps that record in memory, in Redis, or in a database.

Your browser never receives that record. It only receives a session ID, a random string that the server uses to find the record again on the next request. I go through the whole flow in cookies vs sessions vs tokens, so I won't repeat it here.

The important part for this article is where it lives. The session is on the server, which means nothing your browser does can delete it. You can close every tab, quit the browser, and reinstall it, and that record is still sitting there until the server decides otherwise.

The session cookie: a rule about when a cookie dies#

This is the one that trips people up the most, because the name sounds like "the cookie that holds the session".

A session cookie is any cookie that was set without an Expires date and without a Max-Age. That's the entire definition. It's not a special type of cookie, and it says nothing about what's inside it. It only tells the browser one thing, which is "keep this until the browsing session ends, then throw it away".

Set-Cookie: sessionId=abc123xyz

That's a session cookie, because there is no expiry on it.

Set-Cookie: sessionId=abc123xyz; Max-Age=1209600

That's a persistent cookie holding exactly the same value. It survives closing the browser, because now the browser has been told how long to keep it.

So a cookie holding a session ID can be either one. A cookie holding your language preference can also be either one. "Session" here describes the lifetime, not the content. Both kinds are sent to the server automatically with every matching request, using the Cookie request header.

sessionStorage: one box per tab#

sessionStorage is a browser API for storing strings, and it is the only one of the three that Javascript on the page is meant to read and write directly.

sessionStorage.setItem("step", "3");
sessionStorage.getItem("step"); // "3"

Two things make it different from everything else. The first one is that it's never sent to the server. No header carries it, and the server has no way to ask for it. If you put something in sessionStorage, only your own Javascript will ever see it.

The second one is that it's scoped to a single tab, not to the whole browser. localStorage is shared by every tab open on the same site, so writing a value in one tab makes it visible in the others. sessionStorage is not. Open the same site in a second tab and that tab gets its own empty box, and the two tabs cannot see each other's values.

That per-tab behaviour is what makes it useful for things like the current step of a multi step form, or a scroll position you want to restore, where two tabs genuinely should not share state.

What ends a server session, a session cookie and sessionStorage?#

Here is where the three finally separate in a way you can test yourself. Each action below is answered for all three, because almost no action ends all of them.

You refresh the page. Nothing ends. sessionStorage survives a reload, the cookies are still there, and the server session is untouched. This surprises people who expect a refresh to clear things, and it is the reason sessionStorage works for multi step forms.

You close the tab. The sessionStorage for that tab is gone. Cookies are not affected at all, because cookies belong to the browser and not to a tab. The server session is untouched, so opening the site again in a new tab leaves you logged in.

You open the same site in a second tab. The new tab gets a fresh, empty sessionStorage. Cookies and the server session are shared normally, which is why you are already logged in there.

You duplicate a tab, or open a link in a new tab from the page. The new tab starts with a copy of the original tab's sessionStorage. It's a copy and not a link, so from that moment the two tabs drift apart independently. This one catches almost everybody at least once.

You close the whole browser. If the site created a session cookie (a cookie without Expires or Max-Age), the browser normally deletes it when the browser session ends. On your next visit, there is no session ID to send, so the site treats you as logged out. But if the developer set an Expires or Max-Age attribute, the cookie is persistent and can survive the browser closing. Either way, the important point is that closing the browser does not delete the server session itself. The server-side record remains until it expires, is invalidated, or is otherwise removed.

You close the browser, but "continue where you left off" is on. Now closing the browser ends much less than you expected. Browsers that restore your previous tabs also restore session cookies and sessionStorage along with them, so you come back still logged in and with your tab state intact. The same thing happens after a crash recovery. If you have ever been unable to reproduce a "logged out on restart" bug, this setting is usually why.

You log out properly. This is the only one that ends the server session, because it's the only one the server hears about. The server deletes its own record, and normally also tells the browser to clear the cookie. Everything else on this list is something the browser did quietly on its own.

You do nothing for long enough. The server session expires on its own schedule and stops being valid, even though your cookie is still sitting in the browser looking perfectly fine.

The server restarts. If sessions are stored in the server's memory, they all disappear and everyone is logged out at once. If they're in Redis or a database, they survive. This is a big reason production apps rarely keep sessions in memory.

Side by side#

The row worth memorising is the second to last one. Closing a tab ends exactly one of the three, and closing the browser ends the browser's copies but never the server's record.

Which one should you reach for?#

If the server needs to know something, it belongs in a server session, with a session cookie carrying the ID. Mark that cookie HttpOnly, Secure and SameSite, because a server can never trust your browser with data it intends to believe later.

If only the page needs it, and only in this tab, and it would be fine to lose it, use sessionStorage. A wizard step, a draft filter, a scroll position.

What you should not do is put a session ID or a token in sessionStorage and treat it as secure. It is not protected from cross site scripting in any way, since any script running on your page can read it. Being cleared when the tab closes feels like a security feature, but it's a lifetime feature, and it does nothing against the attack that actually matters.

Frequently asked questions#

Is a session cookie the same as a session ID?

No. The session ID is the value, and the session cookie is the envelope with no expiry date on it. You can send a session ID in a persistent cookie, and you can send something completely unrelated in a session cookie.

Does closing the browser log me out?

It usually looks that way, but the server session is still alive. Your browser simply dropped the session cookie, so it stopped identifying you. If tab restore is enabled, even that doesn't happen and you come back logged in.

Why is my sessionStorage empty in a new tab, but full in a duplicated one?

Because duplicating a tab copies the box, while opening a new tab creates an empty one. It's the intended behaviour, and it's the most common source of confusion with sessionStorage.

Can the server read sessionStorage?

Never, unless your own Javascript reads it and sends the value in a request. There is no header and no mechanism that exposes it automatically.

Related reading#

• Cookies vs Sessions vs Tokens: How websites keep you logged in
• Why a server can never trust your browser
• Seven HTTP request headers every developer should understand
• Why your cookie is not being set

What that explanation leaves open is how any of it is possible, because underneath there is no magic storage layer. The database is writing to the same filesystem your JSON file was on, with the same disk and the same ways of failing. Something has to be different about how it writes, and that something is the whole subject of this article.

This is the layer most developers never look at, which is a shame, because it explains a surprising number of things that otherwise look arbitrary. Why committing a large transaction is fast. Why adding an index slows down your inserts. Why "the database is slow" is so often a memory problem rather than a disk one.

It really is still files#

Start with the deflating part. If you open a PostgreSQL data directory you find files and folders. Every table is a file, or several once it grows past a size limit. A SQLite database is one single file that you can copy with cp and email to someone, which is a large part of why it ended up inside phones, browsers and aeroplanes.

So the difference between a database and the users.json you would have written yourself is not where the bytes live. It is the discipline with which they are put there, and that discipline comes down to three ideas: the file is divided into blocks, changes are written down before they are applied, and a second sorted structure exists so nothing has to be scanned.

Pages, not one big blob#

The first decision is that the file is not one continuous document. It is divided into fixed-size blocks called pages, usually 4 or 8 kilobytes each, and rows are packed into them.

   users table file
 ┌──────────┬──────────┬───────────┬──────────┐
 │  page 0  │  page 1  │  page 2   │  page 3  │
 │ rows 1-42│rows 43-88│rows 89-131│   free   │
 └──────────┴──────────┴───────────┴──────────┘
      8 KB      8 KB       8 KB       8 KB

This one choice solves the rewrite problem at the physical level. To change a single row, the engine reads the one page holding it, edits it in memory, and writes that page back. Your JSON file had to be serialised and rewritten in full for a one-character change, because there was no way to address a part of it. A page is the smallest unit the database ever reads or writes, and the size is not arbitrary either: disks, filesystems and databases all converge on similar block sizes because the hardware underneath transfers data in blocks anyway.

The buffer pool#

Pages also give memory a natural unit to work with. The engine keeps recently used pages in a region of RAM called the buffer pool, so a row that was read a moment ago is served without touching the disk at all. Reads check the pool first, and only pages that are not there cause actual disk activity.

This is where a lot of real-world database performance actually lives. A well-tuned database serves the large majority of its reads from memory, and the phrase "the database is slow" often means nothing more exotic than the working set having grown past what the buffer pool can hold. The queries did not change, the data did, and suddenly reads that were memory lookups became disk reads.

Writes go through the pool too. A modified page sits in memory marked as dirty, and gets written back to the table file later rather than immediately. Which raises the obvious question: if the change is only in memory, what happens when the machine dies?

The write-ahead log#

Writing pages back in place is the dangerous moment. A crash halfway through leaves a page that is neither the old version nor the new one, and a half-written page is worse than a lost one, because nothing about it announces that it is broken.

The solution is to not touch the real pages first. Before changing anything, the engine appends a description of the change to a write-ahead log, a file that is only ever written to at the end, and waits for the disk to confirm that the append is physically durable. That confirmation is the fsync call, and it is the moment the promise becomes real. Only after it returns does the database report success to you.

  COMMIT
     ↓
  append change to the write-ahead log
     ↓
  fsync            ← the disk confirms it is really there
     ↓
  report success to the client
     ↓
  update the table pages later, in the background

Why this is fast rather than slow#

It looks like extra work, and it is, but it is cheap work in the right place. An append to the end of one file is close to the least expensive thing you can ask a disk to do, because it is sequential and touches one location. Updating the actual pages is expensive by comparison, since a transaction can dirty pages scattered all over a large table file.

The log lets the database pay the cheap cost on the critical path, while you are waiting, and defer the expensive one to a background process that can batch and reorder it. That is why committing a transaction returns faster than the amount of work it implies, and it is the same trick that makes a database with careful durability guarantees outperform a naive implementation with none.

Crash recovery#

Now the payoff. If the machine dies at any point after that fsync, the log still contains every committed change that had not yet made it into the table files. On startup the engine reads the log and replays them, so nothing acknowledged is lost. It also finds transactions that were partway through with no commit record, and reverses their effects, so nothing half-finished survives either.

That single pass is why a database comes back consistent after a power cut and your JSON file does not. It is also, concretely, what the durability in ACID buys you, and why turning off synchronous commits for speed is a real decision with a real cost rather than a free tuning win.

What an index is on disk#

The last piece of the layout is the one that makes queries fast. An index is a second structure, stored in its own pages, holding the values of one column in sorted order alongside pointers to where the full rows live.

Sorted order is the entire point, because it means a lookup can halve the search space repeatedly instead of walking through everything. Most indexes are a B-tree, a deliberately shallow tree whose nodes are pages, so finding one row among ten million is typically three or four page reads rather than ten million comparisons.

                 [ M ]
            ┌──────┴──────┐
          [ F ]         [ T ]
        ┌───┴───┐     ┌───┴───┐
     A..E     G..L  N..S     U..Z
      ↓                        ↓
   row pointers into the table pages

Three levels like that already cover an enormous number of rows, which is why an indexed lookup feels instant and the same query without one crawls. It is also why the improvement is so dramatic rather than incremental: you are not making the scan faster, you are avoiding the scan.

The cost is worth stating plainly. Every index is more data on disk, and every insert, update or delete has to modify the indexes as well as the table. Indexes are not free speed, they are a trade of write cost and storage for read cost, and how to choose them well is a subject that deserves its own article.

If you would rather see all of this than take my word for it, SQLite is the readable version. Its file format documentation lays out the pages, the B-trees and the header byte by byte, for an engine that is one file on disk and running in more places than every other database combined.

What this explains in practice#

The point of knowing the layout is that a set of otherwise disconnected symptoms turn out to be the same few facts.

A bulk import that slows down as it runs is usually index maintenance, since every row inserted has to be placed into every index as well as the table. Dropping the indexes, loading the data and recreating them afterwards is a standard trick precisely because rebuilding an index once is cheaper than maintaining it a million times.

A table that keeps growing on disk after you delete rows is not a bug. Engines that keep multiple row versions for concurrency mark the old ones as dead rather than removing them immediately, leaving gaps inside pages that later writes can reuse. The space comes back to the table, not always to the filesystem, which is why database sizes tend to rise and plateau rather than shrink.

A query that was fast last month and is slow now, with no code change, is very often the buffer pool. The data grew past the point where the pages it needs stay resident, and reads that were memory hits became disk reads. That extra waiting lands squarely in the gap between the request and the first byte of the response, which is why storage problems show up first as a slow-feeling website rather than as anything obviously database shaped. The fix is more memory, a better index, or asking for less data, and knowing the layout is what tells you which of the three you are actually looking at.

Wrapping up#

Nothing at this layer is mysterious once you see the constraint the designers were working against. A disk can only promise that small, sequential, confirmed writes have really happened, and everything else has to be built out of that one guarantee.

Pages exist so a change touches a small addressable unit instead of a whole file. The buffer pool exists because memory is orders of magnitude faster and pages are the natural thing to cache. The write-ahead log exists because a durable append is cheap and a durable scattered update is not. Indexes exist because sorted data can be searched without being read.

Four ideas, and they hold across almost every engine you will meet, relational or not. The names change and the details differ, but a storage layer that did not do these things would have to invent them.

Key takeaways#

• A database stores data in ordinary files. What differs from a hand-rolled store is the discipline of how those files are written, not the storage underneath.
• Files are divided into fixed-size pages, typically 4 or 8 kilobytes, so changing one row rewrites one small block instead of the entire file.
• The buffer pool keeps hot pages in memory, and a database that suddenly feels slow has often outgrown it rather than developed a query problem.
• The write-ahead log is appended and flushed to disk before the real pages change, which is both what makes commits durable and what makes them fast.
• Crash recovery replays committed changes from the log and reverses uncommitted ones, which is exactly what durability in ACID means.
• An index is a sorted B-tree in its own pages, turning a scan of millions of rows into three or four page reads, paid for with disk space and slower writes.

Frequently asked questions#

How does a database store data on disk?#

In ordinary files, organised into fixed-size blocks called pages, usually 4 or 8 kilobytes each. Rows are packed into pages so the engine can read or rewrite one small block rather than the whole file, indexes live in their own pages as sorted trees, and a separate write-ahead log records every change before the table pages are touched.

What is a write-ahead log?#

A file the database appends every change to, and flushes to disk, before updating the actual table data. Because the log is written first, a crash can never leave the tables in an unrepairable half-finished state: on restart the engine replays committed changes from the log and reverses anything uncommitted.

What is a page in a database?#

The smallest unit of data a database reads from or writes to disk, typically 4 or 8 kilobytes. Rows are stored inside pages, and the engine loads whole pages into memory rather than individual rows, which is why the size matches the block sizes used by disks and filesystems.

What is a buffer pool?#

The region of memory where a database keeps recently used pages so repeated reads do not touch the disk. Most of a healthy database's reads are served from it, and performance often falls off when the data actively being used grows larger than the pool.

Why do indexes make writes slower?#

Because every insert, update or delete has to modify each index as well as the table itself. One table with five indexes means six structures to keep correct on every write, which is why loading large amounts of data is often faster with the indexes dropped and rebuilt afterwards.

Is SQLite a real database?#

Yes. It implements pages, B-tree indexes, transactions and crash recovery like any other engine, with the difference that it runs inside your application process instead of as a separate server. That makes it a poor fit for many machines writing at once and an excellent one for almost everything else.

Continue reading#

• What is a database?. The layer above this one: what a database guarantees, why plain files break, and the types of database engines you can choose between.
• What is a server, really?. The database is one of four jobs behind a typical website, and this covers how the others fit around it.

The usual answer is "put it in the database", and that sentence gets repeated so often that nobody stops to ask what the database is actually doing for you. I used it for years as a place where data goes, roughly a spreadsheet with a login. That picture is not wrong exactly, but it hides the interesting part, which is that almost everything a database does is there to solve a problem you would have hit anyway.

So let's do this the other way around. Instead of starting with tables and SQL, let's start with a file, break it, and see what has to be invented to fix it.

What is a database?#

A database is an organised collection of data, stored in a way that lets you find, change and protect it reliably while many things are using it at once.

The important half of that sentence is the second half. Storing data is the easy part, and your filesystem already does it. What a database adds is a set of guarantees about what happens when things go wrong: two people writing at the same moment, a process crashing halfway through an update, a query that must not read half-finished work. Everything else, the tables, the query language, the indexes, exists to serve those guarantees.

Worth separating one piece of vocabulary early, because it causes real confusion later. The database is the data itself. The DBMS, or database management system, is the software that owns it and answers questions about it. Postgres, MySQL, SQLite and MongoDB are database management systems. In everyday conversation people say "database" for both, which is fine, right up until someone says "the database is down" and you cannot tell whether they mean the data is corrupted or a process stopped listening.

Why not use plain files?#

Here is the honest version of how most of us first solve this problem. You have some users, you have JSON, and you have a filesystem.

import { readFile, writeFile } from "node:fs/promises";

async function addUser(user) {
  const users = JSON.parse(await readFile("users.json", "utf8"));
  users.push(user);
  await writeFile("users.json", JSON.stringify(users));
}

This works. It genuinely works, and for a script that runs once on your laptop it is the correct amount of engineering. It also contains four separate disasters waiting for the day something real happens to it, and walking through them is the fastest way to understand what a database is for.

Two writes at the same time#

Two requests arrive within a few milliseconds of each other. Both read the file and both get the same array of a hundred users. The first adds Ana and writes a hundred and one users. The second, working from the copy it read before Ana existed, adds Bruno and writes its own hundred and one users over the top.

  Request A                Request B
      ↓                        ↓
  read 100 users          read 100 users
      ↓                        ↓
  add Ana                  add Bruno
      ↓                        ↓
  write 101                write 101
                               ↓
                     Ana is gone forever

Nothing errored. No log line appeared. Ana filled in a signup form, saw a success message, and does not exist. This is called a lost update, and the thing that makes it genuinely nasty is that it happens more often the more successful you are, and it leaves no evidence behind.

The crash in the middle#

Now imagine the write itself is interrupted. The process is killed, the container is recycled, the machine loses power. Your file is halfway through being replaced, so what is on disk is not the old list and not the new one. It is a truncated fragment of JSON that will throw a parse error on the next read, and the previous good version is already gone.

A single write is bad enough. Real operations are usually several writes that only make sense together, like taking money out of one account and putting it into another. If the machine dies between the two, the money has left one place and arrived nowhere, and no amount of careful coding on your side can make two separate file writes happen as one indivisible event.

Finding one thing means reading everything#

To find the user with the email address you were given, you read the entire file into memory and loop. At a hundred users that is instant. At ten million it is a very slow request that also allocates a few gigabytes of memory to answer a question about one row.

The fix is to keep a second structure on the side that maps email addresses to positions in the file, so you can jump straight there instead of scanning. That is an index, and it is the single biggest reason a database can answer in milliseconds what your loop answers in minutes. For now it is enough to know that the database keeps extra sorted copies of your data specifically so it never has to read all of it, and what that looks like on disk is worth seeing once.

Relationships have nowhere to live#

Users have orders, orders have line items, line items point at products. In one JSON file you either nest everything, which means the same product description is duplicated in ten thousand orders and updating it means rewriting all of them, or you split into several files and hand-maintain the references between them. Then you delete a user and their orders are still there, pointing at somebody who no longer exists, and nothing in your system considers that an error.

What does a database actually give you?#

Every one of those failures has a name and a solution, and those solutions are what you are buying when you install Postgres instead of writing to a file.

Transactions: all of it, or none of it#

A transaction is a group of operations that the database treats as a single indivisible step. Either every statement inside it takes effect, or none of them do, and there is no state in between that anyone can observe.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

If the power goes out after the first update, the database does not leave you with money that vanished. On restart it notices the transaction never committed and rolls it back, and the accounts look exactly as they did before anyone tried. This is the guarantee that plain files cannot give you at any price, because the filesystem has no concept of "these two changes belong together".

Those guarantees are usually described with the acronym ACID: atomicity (all or nothing), consistency (the data obeys its rules before and after), isolation (concurrent transactions do not see each other's half-finished work) and durability (once it says committed, it survives a crash). The PostgreSQL documentation on transactions walks through the same bank transfer example, which tells you how central this one scenario is to the whole design.

Concurrency: many writers, one truth#

Isolation is the answer to the lost update from earlier. The database does not let two transactions read the same row, decide independently, and both win. Depending on the engine and the isolation level, it either makes the second one wait until the first has finished, or lets both proceed optimistically and refuses to commit the one whose assumptions turned out to be stale.

You still have to ask for the right behaviour. Reading a balance in one statement and writing a new one in another is the same race you had with files, even inside a transaction, which is why UPDATE accounts SET balance = balance - 100 is safer than reading the balance into your application and sending back a number you calculated yourself. The database can only protect what it can see, so the more of the logic you express as a single statement, the more of it is covered.

Durability: what committed really means#

When a database returns success on a commit, the change is already somewhere that survives a crash. Not necessarily in the table itself, which might still be sitting in memory waiting to be written out, but in a record on disk that is enough to reconstruct it. That record is called the write-ahead log, and it is the trick that lets a database be fast and safe at the same time rather than trading one for the other.

A query language instead of a loop#

With files, the code that answers a question is your code. You read everything, filter, sort, count, and if you want the ten most recent orders per customer you write that yourself and hope it is efficient. SQL inverts that. You describe the result you want, and the engine's query planner decides how to get it, which index to use, which order to join the tables in, whether to sort or hash.

SELECT u.email, COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.email
HAVING COUNT(o.id) > 5;

That question, asked over millions of rows, would be a genuinely difficult program to write by hand and an even harder one to keep fast. Here it is five lines, and the planner rewrites the strategy on its own as the data grows and the shape of the tables changes.

Constraints: rules the data cannot break#

The last thing a database gives you is the ability to state what must always be true, and to have those rules enforced no matter which piece of code is doing the writing. A column can be declared unique, so two accounts can never share an email address. A foreign key can require that every order points at a user that actually exists, so deleting a user either cleans up their orders or is refused outright. A NOT NULL says this field is never allowed to be missing.

This matters more than it first appears, because your application is not the only thing that will ever touch this data. There will be a migration script, an admin panel, a background job, a colleague fixing something by hand at eleven at night. Validation in your application protects one path in, and the same reasoning that explains why a server can never trust your browser applies one layer deeper: the database should not fully trust the application either. Constraints are the last line, and they hold for every path.

Under the hood, it is still files#

Worth deflating one thing before moving on, because it makes the rest easier to think about. A database is a program storing your data in files on an ordinary filesystem. There is no exotic storage layer underneath. Open a Postgres data directory and you find files, and a SQLite database is one single file you can copy with cp.

So the difference between a database and your users.json is not where the bytes live. It is the discipline with which they are written, and it comes down to three ideas. The file is divided into fixed-size blocks called pages, so changing one row rewrites one small block instead of everything. Changes are appended to a write-ahead log and confirmed on disk before the real pages are touched, which is what makes a commit both durable and fast. And a sorted structure called an index is kept alongside the data, so a lookup never has to read all of it.

That layer explains more than it first appears, including why adding an index slows down your inserts and why a database that suddenly feels slow has usually outgrown its memory rather than developed a query problem. How a database stores data on disk goes through all of it properly.

What are the different types of databases?#

Everything so far describes the shape most people mean by "a database". It is not the only shape, and the different types of databases exist because they make different trades against the same set of problems.

What separates one database type from another is the database structure, meaning how records are organised and how relationships between them are expressed. That single decision determines which questions the engine can answer quickly and which ones it has to work hard for. You will also see these described as types of database management system, since strictly it is the software that differs rather than the data sitting inside it.

Four types cover almost everything you will meet in practice, followed by a group of specialists built for one access pattern each.

Relational databases#

In a relational database, data lives in tables. A table is a fixed set of columns with declared types, and each row is one record. Relationships are expressed by storing a reference to another table's key rather than nesting the data inside.

     users                         orders
 ┌──────────────┐            ┌────────────────┐
 │ id           │◄───────────│ user_id        │
 │ email        │            │ id             │
 │ created_at   │            │ total_cents    │
 └──────────────┘            └────────────────┘
   one user                    many orders

A user's email address lives in exactly one place, in the row that owns it, so correcting a typo is a single write no matter how many orders point at that user. That principle is called normalisation, and it trades a little query complexity, since you now have to join tables back together, for the guarantee that no fact is stored twice and able to disagree with itself.

The rigidity is doing real work. Because the engine knows every column and type in advance, it can enforce constraints, plan queries intelligently, and refuse writes that would corrupt the shape of your data. Postgres, MySQL, SQLite, SQL Server and Oracle all sit here, and they are what people mean by SQL databases, since they share a query language with the same core in each of them.

The price is that the shape has to be decided up front and changed deliberately. Adding a field means a migration, and if the thing you are storing genuinely has no stable shape, you spend your life fighting the schema.

Document databases#

A document database stores records as self-contained documents, in practice JSON, with no required schema. MongoDB is the common example.

  relational                  document
  ┌──────────┐                {
  │ users    │                  "email": "ana@x.com",
  ├──────────┤                  "orders": [
  │ orders   │                    { "total": 4200 },
  ├──────────┤                    { "total": 990 }
  │ items    │                  ]
  └──────────┘                }
  joined at read time         stored together

The pitch is that a record you read together is stored together, so fetching a user with their orders is one lookup rather than a join, and two documents in the same collection can have completely different fields. That suits data with a genuinely irregular shape, like product catalogues where every category has different attributes, or event payloads from many sources.

What you give up is the engine's ability to enforce anything about that shape. Nothing stops half your documents spelling a field emailAddress and the other half email, so the validation has to live in application code, and the rules only hold for the paths that go through it. Duplication comes back too: if a product name is embedded in ten thousand orders, changing it is ten thousand writes. Modern MongoDB does support multi-document transactions, which is a real change from the version most opinions were formed on, but the design still pushes you toward keeping related data in one document rather than spreading it.

Key-value stores#

A key-value store like Redis does one thing: give it a key, it gives you back a value, extremely fast. There is no query language, no joining and usually no schema, and the data typically lives in memory rather than on disk.

That narrowness is the feature. Redis answers in microseconds, which makes it the standard choice for caching, rate limiting, queues and session storage. It is rarely the place your actual data lives, because memory is expensive and durability is optional. Think of it as a very fast layer sitting in front of a database rather than a replacement for one.

Wide-column stores#

A wide-column store like Cassandra looks superficially like a table, but it is built around spreading data across many machines from the start. Rows are grouped by a partition key that decides which machine holds them, and queries that follow that key are fast while queries that ignore it are difficult or impossible.

That constraint is the trade. You design the structure around the queries you already know you need, rather than storing the data neutrally and deciding later, and in exchange you get write throughput and resilience that a single primary machine cannot match. It is the right answer at a scale most applications never reach, and an awkward one below that.

The specialists#

Past those four, engines get built for one access pattern that the general-purpose ones handle poorly. Time series databases like InfluxDB or TimescaleDB assume data arrives in timestamp order and is queried in ranges, which lets them compress enormously. Search engines like Elasticsearch build inverted indexes so full-text queries rank results instead of matching them exactly. Graph databases like Neo4j store relationships as first-class objects, so "friends of friends who live in this city" is a traversal rather than a pile of self-joins. Columnar warehouses like ClickHouse or BigQuery store data by column instead of by row, which is what makes analytical queries over billions of rows practical.

The pattern is always the same. Each one wins by assuming something about how you will ask questions, and each one loses whenever you ask a different kind.

So, SQL or NoSQL?#

Worth saying plainly, because the internet is loud about this and the decision is calmer than the arguments. "NoSQL" is not a category so much as a label for everything that is not relational, which is why comparing it as one thing rarely helps.

A relational database is the safer default for most applications. You get transactions, enforced constraints and a query planner without having to give anything up, and Postgres has had JSON columns for years, so the "my data is unstructured" case is covered inside the relational model. The honest test is whether you can name in one sentence the specific property you need that a relational engine handles badly, such as a genuinely unpredictable document shape, full-text ranking, or a write volume beyond what one primary machine can absorb. If you cannot name it, you are choosing based on the argument rather than the problem.

Most real systems end up with more than one anyway: a relational database holding the facts, Redis in front of it for caching, perhaps a search index alongside. That is not indecision, it is each store doing the job it is shaped for.

What is a database server?#

A database server is the program that owns the data and answers queries about it, listening on a port and waiting for connections in the same way any other server does. Postgres listening on 5432 is a database server. The word is also used for the machine that program runs on, which is the same double meaning the word server carries everywhere.

It is one of the four jobs behind a typical website, and on a small project it runs on the same machine as everything else, as one more process alongside your application.

   Your application  :3000
          ↓  SQL over a connection
   Database server   :5432
          ↓
   Files on disk

When it moves to its own machine, nothing about the model changes, only the distance. A query that was a local socket call becomes a network round trip that can be slow, time out, or fail entirely, and your application has to have an opinion about what to do when it does. Connection pools exist because opening that connection is expensive enough that you want to keep a handful open and reuse them.

That same distance is why so much of a request's time is spent waiting rather than computing, and why runtimes built around not blocking while waiting for I/O were such a good fit for web workloads. Your server is rarely busy. It is usually waiting for the database to come back.

Who is allowed to talk to it is an architectural decision with real consequences. One shared database that every service reads and writes is simple and consistent, but it couples everything to one schema, and changing a column becomes a negotiation between teams. Giving each service its own is the other end of the same trade-off at the centre of monoliths versus microservices, and it buys independence at the cost of never being able to join across the boundary again.

What developers usually get wrong#

The first misconception is that the database is a passive bucket, so all the logic should live in the application. In practice the engine knows things your code cannot: which index exists, how many rows match, what other transactions are currently doing. Pulling ten thousand rows into memory to filter them in Javascript is slower and less correct than asking for the ones you want.

The second is treating an ORM as a replacement for understanding the database. An ORM maps rows to objects, which is genuinely useful, and it also makes it effortless to write a loop that issues one query per iteration without noticing. Knowing what SQL your code is producing is not an advanced skill, it is the baseline for using an ORM well.

The third is assuming the database is where everything belongs. It is the right home for facts you must not lose, and a poor home for things like large files or a stream of events that nobody will read twice. Sessions are the interesting middle case, because keeping them server-side means the database is consulted on every single request, which is one of the trade-offs behind how websites keep you logged in.

And the fourth, which is less a misconception than a warning: what you store is a liability as much as an asset. The reason websites cannot tell you your own password is that the sensible thing to keep in a users table is a hash and never the original, and the same instinct applies to everything else you are tempted to save because it might be useful one day.

Wrapping up#

A database is not a spreadsheet with a login. It is the piece of your system that has agreed to be careful, and the guarantees it makes are the ones you would eventually have to build yourself, badly, if it did not exist.

Every feature traces back to a failure in the file version. Transactions exist because a crash can land between two writes. Isolation exists because two requests can arrive at the same instant. Indexes exist because scanning everything to find one row stops working at exactly the moment you start succeeding. Constraints exist because your application will not be the only thing writing to this data.

That is also the useful way to keep learning about them. When something in a database seems arbitrarily complicated, it is almost always the scar tissue from a specific way that data goes wrong, and finding the failure it was built for makes the design obvious in a way no amount of documentation does.

Key takeaways#

• A database is more than storage. It is a set of guarantees about correctness while many things read and write at the same time.
• The database is the data, the DBMS is the software that owns it, and the word gets used for both in conversation.
• Plain files break in four predictable ways: concurrent writes silently overwrite each other, crashes leave half-finished state, finding one record means reading all of them, and relationships have nowhere to live.
• Transactions make several operations happen as one indivisible step, so there is no observable state where half of them applied.
• Constraints enforce the rules for every path into the data, including migrations, admin tools and manual fixes that never touch your application code.
• Underneath, a database is still files on a normal filesystem. What differs is the discipline: fixed-size pages instead of one blob, a write-ahead log appended before anything is changed, and sorted index structures so a lookup never scans everything.
• The types of database differ by what they assume about your questions. Relational enforces shape and joins, document trades that enforcement for flexibility, key-value trades everything for speed, and the specialists win on one access pattern each.
• The database is a server on a port, and moving it to its own machine turns every query into a network call that can be slow or fail.

Frequently asked questions#

What is the difference between a database and a DBMS?#

The database is the stored data itself. The DBMS, or database management system, is the running software that organises it, enforces the rules and answers queries, such as PostgreSQL, MySQL or MongoDB. This is why types of database management system and database types mean the same thing in practice: it is the software that differs, not the data. People say "database" for both, which is only a problem when it is unclear whether the data or the process is the thing that has gone wrong.

Is Excel a database?#

Not in any useful sense. A spreadsheet stores rows and can filter them, but it has no transactions, no enforced types or relationships, and no way to handle many people writing at once without someone's changes being lost. Those are the specific problems a database exists to solve.

Can I use a JSON file instead of a database?#

You can, and for a single-user script it is a reasonable choice. It stops working as soon as two requests can arrive at the same time, because both read the same version and the second write erases the first, and a crash mid-write can leave the file unreadable with no earlier copy to fall back on.

What does ACID mean?#

ACID describes four guarantees a transactional database makes: atomicity, so a transaction applies fully or not at all; consistency, so the data still obeys its rules afterwards; isolation, so concurrent transactions do not see each other's unfinished work; and durability, so a committed change survives a crash.

What are the main types of databases?#

Relational databases store rows in tables with a fixed schema, document databases store schema-free nested documents, key-value stores map one key to one value in memory, and wide-column stores spread table-like data across many machines. Alongside those sit specialists built for one access pattern: time series, full-text search, graphs and columnar analytics.

SQL or NoSQL, which should I use?#

For most applications, a relational database is the safer default, because you get transactions, constraints and a query planner without giving anything up. Reach for something else when you can name the specific property you need that relational engines handle poorly, such as an unpredictable document shape or a write volume beyond what one primary can take.

Does the database have to run on a separate machine?#

No. It is a process listening on a port, and running it alongside your application is completely normal for small projects. Separating it becomes worthwhile when you want to scale, back up or restart the two independently, and the cost is that every query becomes a network call.

Continue reading#

Three articles pick up the threads this one leaves hanging, one on the storage layer underneath, one on the machine it runs on, and one on who is allowed to talk to it.

• How a database stores data on disk. Pages, the write-ahead log, crash recovery and what an index physically is, which is where the guarantees in this article are actually implemented.
• What is a server, really?. The database server is one of four jobs behind a typical website, and this covers the other three and how they fit together.
• Monolith vs microservices explained. What happens to your data when the application splits into services, and why one shared database is the decision that usually decides the rest.

For a long time mine was a black box in a cold room somewhere. That picture is not wrong, but it is only one third of the story, and it is the least useful third for a developer.

The reason the word feels vague is that it is doing three jobs at once. Sometimes it means a physical machine. Sometimes it means a program running on that machine. Sometimes it means neither of those and the speaker is talking about a rented slice of someone else's hardware. All three uses are correct, which is exactly why the word slides around in conversation.

So let's take the three apart, one at a time.

What is a server?#

A server is something that waits for requests and answers them.

That is the whole definition. Not a kind of hardware, not a brand, not a place. It is a role in a conversation. Something asks, something answers, and whichever side does the answering is the server for that exchange.

The other side of that conversation is the client. Your browser is a client. So is a mobile app, a curl command, or a payment provider calling your webhook. The naming describes who starts the conversation and who responds to it, nothing more.

A server is not necessarily a separate computer#

A server does not have to be a special machine sitting in a data centre. It is usually a program running on a computer.

Your laptop can be a server. Your phone can be a server. A program inside a virtual machine can be a server.

What matters is the role the program is playing: it waits for requests and responds to them.

This is why the same machine can be both. Your application server is a server when the browser talks to it, and a client the moment it turns around and queries the database. The role changes depending on which conversation you are looking at.

The practical consequence is that there is nothing special about the machine. The laptop you are reading this on can be a server in about ten seconds, and later in this article we will do exactly that. What makes something a server is that a program on it is listening, and that it stays running when nobody is using it.

That last part matters more than people expect. A client can make a request and disappear. A server needs to be available when the request arrives, which is where all the boring requirements come from: uptime, restarts, monitoring, and reliable infrastructure.

Is a server hardware or software?#

Now the confusing part. When someone says "the server", they might mean the metal or they might mean the program, and the sentence usually does not tell you which.

When server refers to hardware, it usually means a computer designed to run services reliably and continuously, often with features that make it easier to operate and maintain remotely. No monitor, no speakers, no concern for looking nice. Instead it has redundant power supplies so one failure does not take it offline, error-correcting memory that catches bit flips instead of quietly corrupting data, drives designed to spin for years, and a flat shape so it slides into a rack with dozens of others. It is optimised to run unattended for a very long time.

The software meaning is a program that listens on a port and answers requests. Nginx is a server. Postgres is a server. The Node process running your API is a server. None of them are objects you could drop on your foot.

One physical machine usually runs several of these at once:

        One physical machine
 ┌───────────────────────────────┐
 │  Nginx        listening :443  │
 │  Your app     listening :3000 │
 │  Postgres     listening :5432 │
 │  SSH daemon   listening :22   │
 └───────────────────────────────┘
     four servers, one computer

This is why "the server is down" is such an unhelpful sentence. The machine could be off, or the machine could be perfectly healthy while one process on it crashed. Those are completely different problems with completely different fixes, and the word covers both.

Worth knowing the habit: when a developer says server they almost always mean the software, and when someone from operations says it they usually mean the machine.

How does a server handle a request?#

Underneath every server, whatever it is written in, sits the same loop.

It opens a port and waits. A connection arrives. It reads the request, works out what is being asked, does whatever work that requires, writes a response back, and goes straight back to waiting. That is the entire lifecycle, repeated a few thousand times a second on a busy day.

Here is the loop as actual code, which is the fastest way to prove that a server is not a mysterious thing:

import express from "express";

const app = express();

app.get("/", (request, response) => {
  response.send("Hello from a server");
});

app.listen(3000);

A handful of lines, and your laptop is now a server. It is listening on port 3000, and anything that can reach that port can ask it for a response. The fact that this is possible in Javascript at all is a fairly recent development.

In HTTP/1.1, the request is transmitted as a text-based message. When a browser talks to a web server, it sends a request describing what it wants, followed by headers that describe who is asking and what they can accept. The server replies with a status code, its own headers, and the body. You can follow that whole journey from the address bar to the pixels here.

Two properties of this loop shape almost everything else.

The first is that HTTP is stateless. The connection underneath may be reused for several requests, but the server does not automatically retain application state from one request to the next. Unless you build something on top, it has no way to know that the request it is handling came from the same person who logged in a minute ago. Everything about staying logged in exists to work around this.

The second is that requests do not politely queue up one at a time. Hundreds can be in flight at once, and how a server handles that overlap is the main thing separating one server technology from another.

What are the main types of servers?#

Here is the thing that took me embarrassingly long to notice. When people say web server, database server or file server, they are not describing four different kinds of computer. They are describing four different jobs, and the same box can do all of them at once.

The names tell you what the software does, not what the hardware is.

What is a web server?#

A web server speaks HTTP. Its job is to accept connections from the outside world and deal with the parts of a request that have nothing to do with your business logic.

MDN describes the same split in its own introduction to what a web server is, hardware on one side and software on the other, which is a good sign that the confusion is not just you.

Nginx and Apache are some of the most common ones you will meet. They serve static files straight off disk, handle the TLS handshake so your traffic is encrypted, compress responses, and pass anything dynamic along to whatever actually generates it. That last job is called reverse proxying, and it is why a web server usually sits in front of your application rather than containing it.

If a request is for /logo.png, the web server answers it alone and your code never runs. If the request is for /checkout, it hands it onward.

What is an application server?#

An application server runs your code. This is the layer where a URL becomes a decision: check who is asking, read from the database, apply the rules, build a response.

Your Express API, your Rails app, your Django project and your Spring service all sit here. The distinction from a web server used to be sharp, because the thing running your code was not built to face the open internet and needed something hardened in front of it. Modern runtimes blur it, since a Node process can happily terminate TLS and serve static files itself. Most production setups still keep the two separate, because the boring layer is very good at the boring work and there is no reason to make your application do it.

What does a database server do?#

A database server owns the data and answers questions about it. Postgres, MySQL, MongoDB and Redis are all servers by the definition we started with, they just do not speak HTTP.

Postgres listens on port 5432 and speaks its own protocol, so you talk to it with a client library rather than a browser. It handles the things you would not want to write yourself: concurrent writes without corruption, transactions that either fully happen or fully do not, indexes that turn a full scan into an instant lookup, and rules about what happens when two people edit the same row at the same moment.

One detail matters more than the rest. A database server should not be reachable from the internet. Only your application should be able to open a connection to it, because a database exposed to the world is the shortest path between a small misconfiguration and a very bad week.

What is a file server?#

A file server stores files and hands them out over a network. Inside a company this is the shared drive that appears on everyone's machine, usually running SMB on Windows networks or NFS on Unix ones, so the files feel local while living somewhere else entirely.

One protocol commonly associated with file servers is FTP, the File Transfer Protocol. For years, it was a common way to upload a website to a host: connect, drag your folder across, done. Today, encrypted alternatives such as SFTP are generally preferred when transferring files over untrusted networks.

The modern version of this job usually is not a file server at all. Object storage like S3 does the same thing over HTTP, with the network drive metaphor dropped completely.

How do web, application and database servers work together?#

Put the main application layers in a line and a normal request looks like this:

   Browser
      ↓
  Web server        TLS, static files, routing
      ↓
 App server         your code, your rules
      ↓
 Database server    the data itself
      ↓
   Response back up the same path

Each layer does one job and hands the rest along. That is the shape behind most of the web, whether the thing serving you is a personal blog or a bank.

What throws people is that this diagram says nothing about how many computers are involved. On a small site all four layers run on one rented machine that costs a few euros a month, and that is a completely legitimate way to run a real application. On a large one, each layer is a separate cluster and there are load balancers, caches and queues in the gaps.

The layers stayed the same. Only the machine count changed.

Splitting them apart buys you the ability to scale each piece independently and to fail in smaller pieces, and it costs you the fact that a function call becomes a network call that can time out. That trade is the same one at the centre of monoliths versus microservices, one level further up.

An example: Vite and Express#

If the layers still feel abstract, here is a stack a lot of people actually run, and the confusion that comes with it. Both answers feel correct depending on when you look.

In development, you are running two servers at once. Vite serves your frontend on port 5173, keeps a connection open so the page updates the moment you save a file, and forwards anything starting with /api to Express on port 3000. Express runs your routes and talks to the database.

   Browser
      ↓
  Vite dev server  :5173    frontend files, hot reload
      ↓                     /api → :3000
  Express          :3000    your code, your rules

The important bit is that the browser only knows about port 5173. If your frontend calls /api/products, the browser sends that request to the same origin it got the page from.

Vite receives it and, because of the proxy setting in your Vite config, forwards the request to Express.

So Express is handling the API request, but the browser never talks to port 3000 directly. This is useful in development because your frontend can call /api/products without having to know where the API server is running, and Vite can take care of forwarding it.

Two processes, two jobs, one browser-facing port.

Then in production, Vite is not there any more. This surprised me the first time I looked for it. Running vite build happens once, writes finished files into a dist folder, and exits. Vite is a build tool that happens to include a dev server for your convenience, not something your application normally runs in production.

So in production the question becomes: who serves that dist folder, and who receives the API requests?

There are a couple of perfectly normal answers.

In the first setup, Express is doing both jobs in a single process. It serves the finished frontend files and runs the API.

In the second, Nginx sits in front. It serves the static files itself and forwards only /api requests to Express:

So why use Nginx at all if Express can already serve the files?

Because serving a few files is easy. Handling the boring infrastructure around those files is something Nginx is very good at. It can terminate HTTPS, serve static files efficiently, compress responses, add caching rules, handle connections, and act as a reverse proxy in front of one or several application processes.

That separation also means Express can concentrate on your application: authentication, business rules, database queries and API responses. Nginx handles the traffic coming in from the outside world.

You do not always need it. A small application can perfectly well have Express serve the frontend and API itself. Nginx becomes useful when you want to separate those responsibilities or need the extra infrastructure features around your application.

And this is the whole point again: these are jobs, not products. Express can perform the application-server job and, in some setups, the web-server job too. Nginx can perform the web-server and reverse-proxy jobs. Asking which one is "the web server" only has an answer once you say which setup, and which moment, you are talking about.

Other types of servers: proxy, DNS, VPS and MCP#

Four types cover the stack behind a website, but the naming pattern keeps going, and the same rule applies every time. The word in front tells you the job.

A proxy server sits between a client and a server and passes traffic along, either to protect the client's identity on the way out or to shield and cache for the server on the way in. A DNS server answers the question of which IP address a domain name points to, which is a whole journey of its own that a single DNS lookup walks through step by step. A DHCP server hands out local IP addresses when a device joins a network, which is why your laptop gets an address the moment it connects to wifi without you configuring anything. A mail server moves email around.

One name in that family breaks the pattern, and it is worth calling out. A VPS, or virtual private server, does not describe a job at all. It describes ownership: a slice of a bigger physical machine, rented to you, that behaves like a whole computer you control. What you run on it is entirely your business.

What is an MCP server?#

The newest name in the family is the one that confuses people most, because it arrived attached to AI and everyone assumed it must be something exotic. An MCP server, from the Model Context Protocol, is a program that exposes tools and data to an AI model in a format the model can call. Your editor's assistant wants to read a file, query your database or open a pull request, and an MCP server is the thing sitting on the other side of that request, deciding what it is allowed to do and handing back the answer.

Held up against the definition we started with, it fits perfectly. Something waits, something asks, an answer comes back. What changed is only who is doing the asking. For thirty years the client was a browser or another program written by a human, and now it can be a model deciding on its own that it needs the contents of a file. The protocol is new, the shape is not, and that is genuinely the whole trick.

Game servers, media servers and time servers#

The pattern keeps going well past web development, and the further out you go the clearer it gets that the word is doing the same job every time. A game server holds the authoritative state of a match and tells every connected player what actually happened, which is the same trust problem a web application has, at sixty updates a second. A media server sits on a machine at home and streams your own files to whatever device asks for them. A time server answers one very small question, what time is it, and it matters more than it sounds, because certificates, logs and distributed systems all fall apart quickly when two machines disagree about the clock.

Different protocols, different ports, different problems. Same loop underneath.

Where do servers live? Data centres, server racks and the cloud#

The hardware meaning has to physically be somewhere, and that somewhere is almost always a data centre.

Inside one, machines are mounted in a server rack, a metal frame a bit under two metres tall holding equipment in standard slots. Each slot is a rack unit, or 1U, about 4.4 centimetres high, which is why servers are sold as 1U or 2U and why they are so unnaturally flat. Stacking them this way means one rack can hold dozens of machines while keeping cabling manageable and letting cold air flow through the front and out the back.

The building around the racks is the actual product. Redundant power feeds with battery backup and generators, cooling that runs constantly because a rack of machines produces a serious amount of heat, multiple independent network connections, and physical security. Very few companies want to own any of that, which is where the cloud comes in.

"The cloud" is not a technology, it is an arrangement. Someone else buys the racks, staffs the building, replaces the failed drives, and rents you the use of the machines by the hour. Virtualisation is what makes it work: one physical machine is divided into many isolated virtual ones, so you get a computer that behaves like it is yours while sharing hardware with strangers.

Nothing about the definition changed. Your code still runs on a specific machine, in a specific building, in a specific country. The only thing that changed is whose name is on the invoice for the hardware, and how quickly you can get another one.

Wrapping up#

The word stops being vague once you know it is carrying three meanings. A machine that stays on, a program that listens, and a rented slice of someone else's hardware. When a sentence confuses you, it is almost always because two people in the room picked different meanings.

Underneath all three is the same small idea. Something is waiting, something asks, an answer comes back. Every type in this article is a variation on that one loop, differing only in what it listens on and what it does before it replies.

Keeping the roles straight also changes how you think about safety. Once you can see that the client and the server are two separate computers owned by two separate people, it becomes obvious why a server can never trust your browser, and a large part of web security follows from there.

Key takeaways#

• A server is a role, not a kind of machine. Whatever answers a request is the server for that exchange, and the same computer can be a server in one conversation and a client in the next.
• The word carries a hardware meaning and a software meaning at the same time, which is why "the server is down" can describe two completely different problems.
• Every server runs the same loop: listen on a port, read a request, do the work, write a response, wait again.
• Web, application, database and file servers are four jobs rather than four machines, and on a small site all four run on one computer.
• The cloud does not remove the physical machine. It changes who owns the rack and how fast you can rent another slot in it.

Frequently asked questions#

Is a server just a normal computer?#

Mostly yes, with different priorities. Server hardware drops the things a desktop needs, like a monitor and a sound card, and adds redundant power supplies, error-correcting memory and a flat shape that fits a rack. Any ordinary computer can act as a server the moment it runs a program that listens for requests.

What is the difference between a web server and an application server?#

A web server handles HTTP itself: encryption, static files, compression, and passing dynamic requests onward. An application server runs your code and produces the answers. In production they are usually separate processes, with the web server sitting in front, though modern runtimes can do both jobs in one.

Can my laptop be a server?#

Yes, and it already is one whenever you run a dev server locally. The difference between that and production is not the hardware, it is that a production server has a public address, stays on permanently, and is expected to survive restarts and failures without anyone watching.

What is a server rack?#

A server rack is a standard metal frame that holds servers and network equipment in stacked slots. Each slot is one rack unit, or 1U, about 4.4 centimetres high, which is why servers are described as 1U or 2U. Racks keep dozens of machines in a small footprint with predictable cabling and airflow.

Do I need my own server to host a website?#

No. Managed hosting, static hosting and serverless platforms all run your site on servers that someone else operates and configures for you. There is still a server answering every request, you are simply not the one maintaining it.

Continue reading#

Two articles pick up directly where this one stops, one on the security side and one on the architecture side.

• Why a server can never trust your browser. Now that the client and the server are two clearly separate machines, this is what follows from it, and it is where most web security starts.
• Monolith vs microservices explained. What actually happens when you take the layers from this article and split them across separate machines, and what that costs you.

You’ve already validated the form. The email field checks for an @, the quantity field rejects negative numbers, and the submit button stays disabled until everything is filled in.

Then the reviewer writes:

This needs to happen on the server too.

First time I saw it, my reaction was that they hadn’t read the code properly. The validation was right there. Why would we write the same thing twice? It felt like the kind of ceremony that exists because a senior developer got burned by it once, and now everyone else has to pay the tax forever.

It took me longer than I’d like to admit to understand that these two checks aren’t duplicates at all. They happen in different places, for different reasons, and they protect you from very different problems.

One is there to help your users. The other is there because the browser belongs to the user, and the user can change whatever they want.

That small idea changes the way you look at a lot of web development.

Once you understand why a server can’t trust your browser, things like server-side validation, authentication, authorization, and even seemingly harmless form checks start to make a lot more sense.

What is the client-server trust boundary?#

Let's say you have created and deployed an online shop.

When someone opens their browser and presses Enter in their address bar, a lot of machinery wakes up. Their browser resolves the domain, opens a connection, and sends a request.

Your server sends back the HTML, CSS, and Javascript that make up your website. That code now runs in the visitor's browser, on their machine.

This is where the important distinction begins: the browser belongs to the visitor; the server belongs to you.

The visitor can inspect your Javascript, change it, open DevTools, disable things, or send requests directly to your server.

You control what happens on the server.

That creates the trust boundary:

      Their machine                     Your server
  ┌─────────────────────┐         ┌─────────────────────┐
  │ Browser             │         │ Server              │
  │ HTML, CSS, JS       │         │ App code, database  │
  │ DevTools, extensions│         │ Nobody else's hands │
  │                     │         │                     │
  │ They control this   │         │ You control this    │
  └─────────────────────┘         └─────────────────────┘
             │                               │
             └──────────  HTTP  ─────────────┘
                    the trust boundary

Anything on the left side is a claim. Anything on the right side is something your application can verify and enforce.

A lot of web security comes down to remembering this boundary, and the expensive lessons that happen when we forget it.

Why client-side validation can be bypassed in seconds#

Imagine now that you’re building a checkout feature for your online shop. The main scenario you have in mind is a customer finding a product and deciding to buy it.

For our example, let’s say the product costs €50.

Your checkout page sends the price in a hidden form field:

<input type="hidden" name="price" value="50">

You also have some Javascript that checks the form before allowing the customer to submit it. You test everything, place a few orders, and everything works. Customers pay the correct price.

The problem is that once your site is in production, the browser is running on the customer's machine. The customer can open DevTools and change what your page sent to their browser.

For example, they could change:

<input type="hidden" name="price" value="50">

to:

<input type="hidden" name="price" value="1">

Now the browser can send 1 as the price.

They could also change or remove a min="1" restriction on the quantity field, remove the Javascript checks, or skip the checkout page completely and send the HTTP request themselves with curl.

This is the important part: the server cannot trust the client to follow the rules defined in the frontend.

And the client doesn't have to be a browser at all. Someone can simply send the request directly:

POST /checkout HTTP/1.1
Host: yourshop.example
Content-Type: application/json

{ "productId": 4417, "quantity": 1, "price": 1 }

From the server's point of view, this is just a normal HTTP request.

HTTP doesn't tell the server:

"This request came from your checkout page, and the user didn't change anything."

The server receives the request and has to decide whether the data is valid.

That's why important values should be checked on the server. Instead of trusting the price sent by the browser, the server should receive the product ID and look up the real price itself.

That’s the part that reframes everything.

Client-side validation isn't weak security. It isn't security at all. It's a user experience feature. It can tell someone their email is missing an @ before they have to wait for a round trip, and that’s genuinely valuable.

In the end, though, the server is the one that has the final say.

The browser can help, but it has no authority.

Which parts of an HTTP request can be spoofed#

Before we dive into which parts of a request can be spoofed, let's first understand what spoofing actually means.

In simple terms, spoofing means pretending to be something you are not.

In the context of web requests, it means a client sends information that makes the request look different from what it really is. The important detail is that the client gets to choose what goes into the request.

Once you understand the trust boundary, a lot of familiar things start looking different. A request is made up of many pieces of information, but the server shouldn't automatically treat all of them as facts.

A useful way to think about this is to group the things a client can send into a few broad categories.

1. Form fields and request data#

This is the easiest category to understand because we just saw it with the checkout example.

A browser might send:

{
  "productId": 4417,
  "quantity": 2,
  "price": 50
}

But the client can change any of those values before sending the request:

{
  "productId": 4417,
  "quantity": 2,
  "price": 1
}

The server therefore cannot trust the price simply because it came from a form your application created.

The same applies to things like:

• quantity
• account IDs
• roles
• permissions
• discount codes
• feature flags
• hidden form fields

If the client sends the value, the client can potentially change it.

2. Request headers#

Headers can also look more trustworthy than they really are.

Take User-Agent. A browser normally sends information about itself:

  User-Agent: Mozilla/5.0 ... Chrome/131.0 ...

Your server might use this for analytics or logging. That's fine. But if you use it as a security check, you're trusting the client to tell you the truth.

A request made with curl can send the same value:

curl https://yourshop.example/api/example \
-H "User-Agent: Mozilla/5.0 ... Chrome/131.0 ..."

Your server sees the same header.

The same idea applies to headers such as Referer. It can tell you where the client says the request came from, but it isn't proof that the request actually came from there. The same caution applies to the rest of the HTTP request headers you'll meet every day, because every one of them is written by the client.

3. Identity and authentication data#

This category is a little different. A client can send a cookie containing a session ID:

  Cookie: sessionId=abc123

The browser is still choosing to send that value. The important question is what the server does with it.

A secure session system doesn't blindly trust the cookie just because it came from the browser. Instead, the server uses the session ID to look up the session in its own store.

But there is still a small amount of trust involved. The server is essentially assuming that whoever presents a valid session ID is the person who should be using that session. It relies on the session ID being kept secret and not being stolen.

So the browser carries the identifier, but the server decides what that identifier means.

The same principle applies to signed tokens. A client can read a token and send it back, but if they modify its contents, the server can detect the change because the signature no longer matches.

So authentication data is still client-provided data. It becomes trustworthy enough to use because the server has a way to verify it, and because the system assumes the credential itself has not been stolen. That verification step is the whole reason user authentication works the way it does, whatever method sits behind it.

That distinction is important: the server doesn't trust the browser; it trusts a credential that it can verify.

4. Network information#

Then there is information that looks like it should describe the connection itself, such as the client's IP address.

This is where things become more complicated because the request may pass through several systems before reaching your application:

  Visitor
     ↓
  Browser
     ↓
  CDN / proxy
     ↓
 Load balancer
     ↓
 Your server

Your application may therefore learn the client's IP from a forwarded header rather than directly from the network connection.

That's why headers such as X-Forwarded-For need special handling. Your application needs to know which proxies it trusts before treating the information they provide as the real client IP.

This is also why rate limiting based on IP can go wrong if the proxy configuration is incorrect.

The important distinction#

All of these examples start with the same basic fact:

The client can send data, but sending data doesn't make it true.

The server has to decide what can be trusted directly, what needs to be validated, and what needs some stronger form of verification. That's the real lesson behind spoofing. You don't need to memorize every header that can be spoofed.

You need to recognize the pattern:

If the client controls the value, treat it as a claim until your server has a reason to trust it.

What a server can safely trust instead#

So if the client can change almost anything in a request, what can the server actually trust?

The answer isn't "nothing." The answer is that the server should trust things it can verify independently.

For example, instead of trusting the price sent by the browser, the server can take the product ID and look up the price in its own database.

Instead of trusting a role sent by the client:

{
  "userId": 123,
  "role": "admin"
}

the server can get the user's role from its own database or session.

Instead of trusting that a session ID is valid because the browser sent it, the server can look it up in its own session store.

Instead of trusting that a token hasn't been changed, the server can verify its signature.

And instead of trusting a password sent by the client by storing it and comparing it later, the server stores a password hash and verifies the password against that hash.

The pattern is the important part.

The server doesn't need to prove that the browser is trustworthy. It doesn't need to know whether the request came from Chrome, curl, Postman, or a script.

It needs to take the claims in the request and compare them against something it can verify independently.

That's the kind of trust that survives the boundary.

Why modern frameworks blur client-side and server-side validation#

The reason this gets confusing in modern codebases is that the line between the browser and the server has become harder to see.

Over the last twenty years, more and more application logic has moved into the browser.

The jQuery era made it easy to validate forms in the browser and give users immediate feedback.

Single-page applications moved even more of the application's logic into the browser, including routing and state.

React made it natural to put logic inside components. A permission check can sit next to the button it controls and look completely legitimate.

Then Node.js put the same language on both sides of the boundary. Now a validation function can look almost identical whether it runs in the browser or on the server.

But none of this changed the trust boundary.

A check in a React component can improve the user experience, but it cannot protect an API. A route guard can hide the admin screen, but the admin API still has to check whether the user is actually allowed to perform the action.

The code moved.

The boundary didn't.

And this doesn't only apply to browsers.

If your server splits into multiple services talking over a network, you've created new trust boundaries where there used to be ordinary function calls.

The same question applies at every boundary:

Does this system actually control the thing it's about to believe?

Client-side vs server-side validation: where each check belongs#

None of this means you should remove your client-side validation. Keep it. It makes forms easier to use, gives users immediate feedback, and avoids unnecessary requests. If someone enters an invalid email address, for example, the browser can point that out immediately instead of waiting for the server to respond. MDN makes the same point in its guide to form validation, which is worth reading if you want the practical details.

The important checks, however, need to exist on the server too. Think about the things your application actually cares about:

• A checkout page can check that the quantity is at least 1, but the server should calculate the final price from the product in the database.
• A frontend can hide an "Admin" button from regular users, but the server must check the user's permissions when the admin API is called. Getting this wrong is common enough that OWASP, the Open Worldwide Application Security Project, ranks broken access control as the number one web application risk.
• A form can require a username and password, but the server still needs to validate both when the request arrives.
• A file upload can limit the file size in the browser, but the server must enforce the limit because someone can upload the file without using your form at all.

The browser's checks make the application nicer to use. The server's checks are what actually enforce the rules.

This isn't about distrusting everything. It's about knowing where a decision is being made and whether the thing making that decision can be controlled by the person you're trying to protect against.

That same idea appears throughout web security: CSRF, CORS, API keys, rate limiting, authentication, authorization, and many other topics are all different ways of dealing with trust across boundaries.

Once you understand that boundary, you don't need to memorize a separate rule for every situation. You can ask the same question each time:

Who controls this value, and how can I verify it?

Key takeaways#

• The trust boundary sits between the browser the user controls and the server that controls the application logic.
• Client-side validation improves the user experience, but it is not a security control. Anything enforced only by the browser can be changed or bypassed.
• Request data is not automatically trustworthy just because it arrived over HTTP. This includes form fields, JSON data, headers, and cookies.
• When something matters, the server should verify it independently using data or mechanisms it controls, such as its database, session store, or cryptographic signatures.
• Modern frameworks have moved more application logic into the browser, but the trust boundary itself has not moved.

Frequently asked questions#

Is client-side validation enough on its own?#

No. Client-side validation gives users immediate feedback, makes forms more responsive, and can prevent unnecessary requests. But the user controls the browser, so they can change or bypass those checks. Important validation must also happen on the server.

Can a server detect if a request came from a real browser?#

Not reliably. Headers such as User-Agent can be changed, and browser fingerprinting is still based on information provided by the client. These techniques can help with bot detection, but they should not be treated as proof that a request came from a trustworthy browser.

Does HTTPS mean I can trust the request data?#

No. HTTPS protects the connection between the client and the server from being read or modified by someone in the middle. It does not tell you that the person or program making the request is trustworthy. A modified or malicious request can still arrive over a perfectly secure HTTPS connection.

Should validation happen on the client or the server?#

Usually, both. Put checks in the browser when they improve the user experience, such as showing that an email address is missing or a required field is empty. Then enforce the important rules again on the server.

For example, the browser can show an error when a username is too short, but the server should enforce the actual minimum length when the request arrives. The browser can also show a countdown before allowing a user to request another verification email, but the server must enforce the rate limit itself.

The two checks have different jobs: the client helps the user; the server enforces the rules.

Then you open a few more pages, refresh the browser, or come back an hour later. Somehow, the website still knows who you are, even though you only entered your password once.

That might feel completely normal, but it's actually a surprisingly interesting problem to solve.

In the previous article of this series, we looked at the different ways websites can authenticate users. But authentication is only the first step.

How does the website remember that it's still You on the next request?

That's what this article is about.

Why your password isn't sent on every request#

If you've read the previous article in this series, you already know that authentication is the process of proving your identity. But that naturally raises another question.

Why isn't your password sent with every request? Why is sending it only once considered the best practice?

At first glance, it doesn't sound like a bad idea.

Every time you open a page, refresh it, or click a link, your browser could simply include your username and password, and the server could verify them before sending a response.

GET /profile

Authentication:
  username: myUsername
  password: MySecretPassword123

And it could do exactly the same thing for every request that follows.

GET /orders

Authentication:
  username: myUsername
  password: MySecretPassword123

GET /settings

Authentication:
  username: myUsername
  password: MySecretPassword123

It sounds simple, but it's actually a terrible idea. Why? Did you ever pause and think about it?

Even though HTTPS encrypts the connection between your browser and the server, sending your password over and over again gives it many more opportunities to leak. It could accidentally end up in application bugs, server logs, browser extensions, debugging tools, or anywhere else sensitive information is handled.

You might be wondering, "But doesn't the website hash my password anyway?"

It does, but only after the password reaches the server. To verify your identity, the browser still has to send the original password every time. The more often that happens, the more opportunities there are for it to be exposed.

Your password really has only one job: to prove who you are. Once the website has verified your identity, there's no reason to keep sending that same secret again and again.

It's a bit like showing your ID when entering a private event. You show it once to prove who you are. After that, nobody asks to see it every time you walk from one room to another. They simply need another way to recognise that it's still you.

So if the website stops asking for your password, what does it use instead?

So what replaces your password?#

Once you've successfully authenticated, the website somehow has to remember who you are.

But why doesn't it already know?

After all, you authenticated just a few seconds ago.

The answer is that HTTP doesn't remember previous requests. Every request is treated independently, so when your browser asks for the next page, the website has no built-in way of knowing that you authenticated a few seconds ago.

Instead of asking for your password again, the server creates a new credential and sends it to your browser. Your browser stores it and automatically includes it with future requests, allowing the server to recognise you without asking for your password again.

Depending on how the application is built, that credential is usually one of these:

• A session ID, where the server remembers who you are.
• A token, where the credential itself carries the information needed to identify you.

In many applications, that credential is stored and sent inside a cookie, although cookies can be used for many other purposes besides authentication.

At this point you've probably noticed three terms coming up repeatedly:

• Sessions
• Cookies
• Tokens

They're closely related, but they aren't interchangeable. Let's see what each one is and how they work together.

Sessions: the server remembers#

When I first heard the term session, I found it a little confusing.

The word made me think of a study session, something that simply has a beginning and an end. While that's not completely wrong, in web development a session usually refers to something much more specific.

A session is a piece of information the server creates after you've successfully authenticated. It allows the server to remember who you are without asking for your password on every request.

Because this information lives on the server, you'll often hear it called a server session. In practice, though, developers usually shorten it to simply session, and both terms normally mean the same thing.

You can think of it as a small record that stores information about your authenticated state.

Session ID: abc123xyz

User: John
Authenticated: Yes
Created: 10:32
Expires: 18:32

Notice that this record contains much more than just your identity. The server can store almost anything it needs for the current session, such as when you authenticated, when the session expires, your permissions, or other temporary information.

Depending on the application, these sessions might be stored in memory, Redis, or a database. Wherever they're stored, the idea is exactly the same: the server keeps the information and uses the session ID to find it again.

The important thing to understand is that this session never leaves the server.

Session never leaves the server

Instead, the server creates a unique session ID that identifies it.

Session ID → abc123xyz

Think of the session ID as the session's unique identifier. The browser doesn't need the whole session; it only needs a way to tell the server which session belongs to it. Keeping the real data on the server side is deliberate rather than incidental, because a server can never trust your browser with anything it would be willing to believe later.

Whenever your browser makes another request, it sends the session ID back to the server. The server looks up the matching session and, if it finds one, immediately knows who you are without asking for your password again.

At this point you might be wondering:

"If the session ID is enough to identify me, what happens if someone steals it?"

That's a great question, and the short answer is that yes, anyone who obtains a valid session ID may be able to impersonate you until that session expires or is invalidated. That's why protecting session IDs is just as important as protecting passwords.

Fortunately, modern browsers and websites include several layers of protection to make stealing session IDs much harder. We'll come back to those shortly.

But before we can understand how they're protected, we first need to answer another question:

How does the browser remember and automatically send the session ID with every request?

Cookies: how the browser remembers#

We've now seen that the server creates a session and sends the browser a session ID.

The next logical question would be: Where does the browser actually keep that session ID?

Browsers can store information in several places, for example:

• Cookies, small pieces of data that are automatically sent with requests to the same website.
• Local storage, data that's stored in the browser and remains there until it's removed.
• Session storage, similar to local storage, but it's cleared when you close the browser tab.

When websites use sessions, the session ID is most commonly stored in a cookie.

When I first learned about cookies, I thought they existed only for authentication.

Ironically, most of us had already heard about cookies for years because of those cookie banners on almost every website, without actually knowing what cookies were. A cookie is simply a small piece of data that a website asks the browser to store. Once stored, the browser automatically includes that cookie in future requests to the same website, using the Cookie request header.

For example, after you authenticate, the server might respond with something like this:

Set-Cookie:
sessionId=abc123xyz

The browser stores that cookie automatically, assuming nothing about the cookie breaks its rules.

From that point on, every request to the same website includes it automatically too.

GET /profile

Cookie:
sessionId=abc123xyz

The server reads the session ID from the cookie, looks up the matching session, and immediately knows who you are.

Notice that, as we discussed earlier, the cookie doesn't contain the session itself. It only contains the session ID. The actual session always remains on the server.

We've now seen the classic solution.

The server remembers who you are by storing a session, while the browser remembers which session belongs to you by storing its session ID in a cookie.

It's a simple approach, but it also means the server has to keep a session for every authenticated user.

What if it didn't have to?

That's where tokens come in.

Tokens: the browser carries the information#

Sessions aren't the only way to keep users logged in.

Instead of asking the server to remember every authenticated user, some applications take a different approach. They give the browser a token that represents the authenticated user.

A token is simply a piece of data that the browser sends with future requests. Unlike a session ID, which is just an identifier, a token usually carries information about the authenticated user.

Conceptually, you can think of a token as containing information like this:

User ID: 123
Role: Admin
Expires: 18:32

Of course, that's not how it's actually sent over the network. Real tokens are encoded into a compact string that the browser sends with each request. One of the most common formats is the JSON Web Token (JWT), which looks something like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Don't worry about understanding that string yet. In the next article, we'll break it apart, piece by piece, and see exactly what's inside it.

For now, the important thing is understanding how tokens differ from sessions.

The following diagram shows the main difference between the two approaches.

The main difference is this.

With sessions, the browser sends a session ID and the server uses it to find the matching session.

With tokens, the browser sends the token itself. Before trusting it, the server verifies that the token is genuine and hasn't been modified. If the verification succeeds, the server reads the information inside the token and identifies the user.

One of the biggest advantages of tokens is that the server doesn't have to keep a session for every authenticated user. This makes them especially popular for APIs, mobile applications, and distributed systems where many different servers may handle the same user's requests.

Just like a session ID, a token can also be stored in a cookie. It can also be stored somewhere else, such as local storage, depending on how the application is designed.

Sessions vs tokens: when to use each?#

Both approaches solve exactly the same problem: remembering who the authenticated user is between requests without asking for their password again.

The biggest difference is where the authentication information lives.

Neither approach is universally better. The right choice depends on the type of application you're building.

Sessions are often the simplest and most common choice for websites where the server generates the pages. Since the server is already handling every request, keeping a session for each authenticated user is usually straightforward.

Tokens are especially popular for APIs, mobile applications, and distributed systems. Because the authentication information travels with the token, any server that receives the request can verify it without having to look up a shared session. This makes it much easier to scale applications across multiple servers.

One final thing that's worth remembering is that these three terms describe completely different concepts.

Although we've used them in the context of authentication throughout this article, they're much broader than that and can be used in many different situations. s

• A session is a way for the server to store information between requests.
• A cookie is a browser feature for storing information and automatically sending it with future requests.
• A token is a piece of data that represents or carries information.

In authentication, these concepts simply become tools that help websites recognise who you are and keep you logged in.

If you remember those three definitions, you'll avoid one of the most common sources of confusion when learning how authentication works.

Explore the series#

We've now seen how websites remember who you are after you've authenticated.

In the next article, we'll take a closer look at JSON Web Tokens (JWTs). We'll open up a real token, see what's actually inside it, learn how it's signed, and understand why servers can trust it without storing a session.

• How user authentication works: the main methods explained
• Cookies vs Sessions vs Tokens: How websites keep you logged in (You're reading this)
• JWT authentication explained: What's actually inside a token? (Coming soon)

The process of answering that question is called authentication. We go through it every day without giving it much thought. You type a password, approve a notification on your phone, or scan your fingerprint, and a few moments later you're logged in.

But what is the website actually checking?

In this article, we'll look at what authentication really means, how it differs from two other security terms that people often mix it up with, and the different ways modern applications can verify your identity. The goal isn't to learn how to build a login form, but to understand why so many authentication methods exist and what each one is trading away. Once you understand those trade-offs, choosing between them becomes much easier.

One thing this article doesn't cover is what happens after you successfully log in. Proving who you are is only the first step. Keeping you logged in across future requests is a different problem with its own design.

Here, we're only focusing on the moment where you prove your identity.

What authentication actually means#

Authentication is the process of proving your identity. You claim to be a particular user, and the website asks for evidence before it accepts that claim. The reason evidence is needed at all is that the claim arrives from outside, and a server can never trust your browser to be honest about who is sitting behind it.

Authenticate = Prove you are who you say you are.

That evidence comes in the form of an authentication factor. A factor is simply a type of evidence you can provide, and almost every authentication method you've ever used fits into one of these three categories:

• Something you know, like a password or PIN.
• Something you have, like your phone or a hardware security key.
• Something you are, like your fingerprint or face.

Each factor has its own weaknesses. Passwords can be guessed or stolen, phones and security keys can be lost, and biometrics can't be changed if they're ever compromised. That's why modern authentication often combines multiple factors instead of relying on just one.

Authentication vs identification vs authorization: what's the difference?#

Now that we know what authentication is, let's clear up two other terms that are often confused with it: identification and authorization.

Identification is simply telling the website who you are, for example by entering your email address. It's only a claim, and anyone can type someone else's email address, so by itself it proves nothing.

Authorization is a different question that only comes after authentication succeeds. Instead of asking who are you?, it asks what are you allowed to do? Can this user view this page, delete this record, or access this API?

Think "I See Zones" (I C Z):

• Identification → I identify myself as Duke.
• AuthentiCation → The website confirms it's really me.
• AuthoriZation → Now that it knows who I am, it decides which zones I can access.

Mixing these terms up can lead to real security bugs. A website might correctly verify that a user is logged in but forget to check whether they're allowed to access a particular resource, allowing them to see or modify someone else's data.

What are the main authentication methods?#

Now that we know the three authentication factors, the different login methods start to make much more sense. They aren't random technologies, they're simply different ways of proving your identity.

*Most passkeys are unlocked with a fingerprint or face, combining two authentication factors in a single step.

We'll start with the simplest methods and gradually move to the more advanced ones:

• Passwords
• One-time password (OTP)
  • SMS codes
  • Email codes
  • Authenticator apps (TOTP)
• Magic links
• Push notifications
• Passkeys
• Social login

Passwords#

Passwords are the most common form of authentication and the classic example of something you know.

When you enter your password, the website verifies it before allowing you to sign in. A well-designed website never stores your actual password. Instead, it stores a password hash, a one-way mathematical transformation created using algorithms such as bcrypt or Argon2.

When you log in, your password is hashed again and the two hashes are compared. If they match, the website knows you've entered the correct password without ever needing to store or recover the original one.

Your password
      ↓
Hashing algorithm (bcrypt / Argon2)
      ↓
Password hash stored in the database

If you'd like to understand why this works, and why websites can't recover your original password, I explain it in why websites can't tell you your password.

Their biggest advantage is simplicity. They don't require any special hardware, everyone knows how to use them, and they're supported almost everywhere.

Their biggest weakness is us. People reuse passwords across websites, choose weak ones, or get tricked into entering them on fake login pages.

One-time password (OTP)#

A one-time password (OTP) is a short code that can only be used once. Even if someone steals the code after you've used it, it becomes useless because it has already expired or has already been used.

OTPs can be used in two ways:

• Instead of a password, as the primary way to authenticate.
• Together with a password, as two-factor authentication (2FA) or multi-factor authentication (MFA).

MFA is simply the more general term for using two or more authentication factors. Two-factor authentication (2FA) is the most common type of MFA.

In the case of 2FA/MFA, after entering your password, you're asked for a second piece of information, such as a code from your phone. This makes your account much more secure because an attacker now needs two different authentication factors instead of just one.

The three most common ways to receive or generate an OTP are:

• SMS codes
• Email codes
• Authenticator apps (TOTP)

SMS codes#

SMS codes are a common form of something you have.

When you set it up, you register your phone number with the website. Whenever it needs to verify your identity, it generates a one-time code and sends it as a text message to that number.

For example:

Your ExampleSite verification code is 482913.
This code expires in 5 minutes.

The security of SMS authentication depends on your phone number. If someone manages to take over that number, they can receive your verification codes instead. One way this can happen is through SIM swapping, where an attacker transfers your phone number to another SIM card.

We'll see why authenticator apps and passkeys avoid this problem in the next sections.

Email codes#

Email codes also use something you have, but instead of sending the code by SMS, the website sends it to your email inbox.

This is generally more convenient, but your account is now only as secure as your email account. If someone gains access to your email, they can receive your login codes too.

When you register your email address, the website can send you a one-time code whenever it needs to verify your identity.

Same as sms code but in your email:

Your ExampleSite verification code is 482913.
This code expires in 5 minutes.

Entering the correct code proves you have access to the registered email account.

Authenticator apps (TOTP)#

Authenticator apps such as Google Authenticator or Microsoft Authenticator are installed on your phone and are used as a second authentication factor.

How it works

1. Install an authenticator app on your phone.
2. On the website, enable two-factor authentication and scan the QR code with the app.
3. The website and the app now share a unique secret that's linked to your account.
4. Every 30 seconds, both use that shared secret together with the current time to independently calculate a new six-digit code. Since they both start with the same information, they always arrive at the same result without communicating with each other.

These codes are called Time-based One-Time Passwords (TOTP) because a new code is generated every 30 seconds using the current time.

The shared secret never leaves your device after setup, and no code is sent over the network. This makes authenticator apps much more secure than SMS or email codes.

If you lose the device containing your authenticator app, you may also lose access to your codes. That's why most websites provide backup codes or other recovery methods that you should save when enabling two-factor authentication.

Magic links#

A magic link removes the need for a password. Instead, you enter your email address and receive a one-time link. Clicking that link proves you have access to your email account and authenticates you automatically.

When you request a magic link, the website generates a unique link that's tied to your account and sends it to your email. Opening that email and clicking the link is enough to prove your identity.

Like email OTPs, magic links rely on something you have, access to your email account. The only difference is that instead of typing a code, you simply click a secure link.

The biggest advantage is convenience. There's no password to remember and no code to copy.

The trade-off is that your account is only as secure as your email account. If someone gains access to your inbox, they can also use the magic links sent to you.

Push notifications#

Push-based authentication is commonly used as part of two-factor authentication (2FA), but it's also used to approve sensitive actions such as payments, password changes, or signing in from a new device.

Whenever the website needs you to confirm your identity or approve an action, it sends a notification to your registered device. The app displays a message such as "Are you trying to sign in?" or "Approve this payment?", and you simply tap Approve or Deny.

Like authenticator apps, this is an example of something you have. Since you never have to type a code, it's both convenient and much harder for attackers to trick you into entering your credentials on a fake website.

One weakness is prompt fatigue. If attackers repeatedly trigger authentication or approval requests, some users eventually tap Approve just to stop the notifications, even though they weren't the ones initiating the action.

Passkeys#

Passkeys are one of the biggest improvements in authentication in recent years. They were designed to replace passwords with something that's both easier to use and much more secure.

Instead of creating a password that you have to remember, your device creates two cryptographic keys that belong together. One key is stored by the website, while the other stays securely on your device and never leaves it.

Whenever you authenticate, your device uses its key to show the website that it's really you. Because the secret key never leaves your device, there's no password to steal, reuse, or accidentally enter on a fake website.

This is what makes passkeys phishing-resistant. Since there's no shared secret to type, there's nothing for a fake login page to capture, even if you're tricked into visiting one.

Most passkeys are unlocked using your fingerprint or face. That means they combine something you have (your device) with something you are (your biometric), giving you a fast login without sacrificing security.

Social login#

Buttons like Continue with Google, Sign in with GitHub, or Continue with Apple are examples of social login.

Instead of creating another password, you simply use an account you already have with Google, GitHub, Apple, or another provider to prove your identity.

Behind the scenes, this is powered by OAuth and OpenID Connect.

The biggest advantage is reducing the number of passwords you need to create and maintain.

The trade-off is that the website no longer verifies your identity itself, it trusts another provider to do that on its behalf. If that provider becomes unavailable or your account is compromised, it can affect your access to every website that relies on it.

Different methods, same goal#

Every authentication method we've looked at answers the same question:

"How can the website be confident that it's really you?"

Passwords, one-time codes, magic links, push notifications, passkeys, and social login all solve that problem in different ways. Some prioritize convenience, others prioritize security, and many try to balance both.

Once your identity has been verified, though, the authentication process is over. The next challenge is remembering that you've already proved who you are without asking you to do it again on every request.

Frequently asked questions#

Why do some websites still use passwords?#

Passwords are simple, familiar, and work on every device. Although passkeys are generally more secure, many websites continue to support passwords for compatibility and because migrating existing users takes time.

Can a website use more than one authentication method?#

Yes. Many websites let you choose between multiple methods, such as a password, a passkey, or social login. Some also combine methods, for example by asking for a password followed by a one-time code as part of two-factor authentication.

Which authentication method is the most secure?#

There isn't a single answer because it depends on the situation. In general, passkeys are currently one of the strongest options because they resist phishing and don't rely on shared secrets like passwords.

What happens if I lose my phone?#

Most services provide recovery methods, such as backup codes, recovery keys, or an alternative authentication method. It's a good idea to set these up before you need them.

Can I use biometrics without passkeys?#

Yes. Biometrics can unlock many different secrets stored on your device, not just passkeys.

Continue the series#

You've seen how websites verify your identity. The next step is understanding how they remember it.

The articles below build on one another, following what happens after authentication succeeds.

• How user authentication works: the main methods (You're reading this)
• Cookies vs Sessions vs Tokens: How websites keep you logged in
• JWT authentication explained (Coming soon)

Most of that framing is wrong, and it makes the decision harder than it needs to be.

The honest answer is that neither one is better. They are simply two different ways of building and deploying an application. Each one solves certain problems while introducing others.

Once you understand those trade-offs, the discussion becomes much simpler. You can look at the problems you're trying to solve and choose the approach that fits best.

The one question that actually separates them#

Forget the debate for a moment. The real difference comes down to one simple question:

"When you deploy your application, are you deploying one unit or many?"

A monolith is one deployable unit. All of your features live in one codebase, they are built together, and they ship together as a single running program. Microservices split that same application into many small programs, each one built and deployed on its own, each one responsible for a slice of the whole.

That is the entire distinction. Not code quality, not team size, not how modern the stack is. It is a question of how many independent pieces you deploy. Everything else people argue about follows from that one fact, so it is worth holding onto as we go.

What a monolith actually looks like#

Picture a typical online store. It has user accounts, a product catalog, a shopping cart, an order system, and payments. In a monolith, all five of those live in the same codebase and run as one process.

        Online store (one deploy)
        ┌───────────────────────┐
        │  Users                │
        │  Products             │
        │  Cart                 │
        │  Orders               │
        │  Payments             │
        └───────────┬───────────┘
                    ↓
              One database

When the cart calls the product catalog to check a price, that is a normal function call inside the same program. The data all lives in one database, so an order can reference a user and a product with a simple join. To deploy, you build the whole thing once and start it on a server. If you need more capacity, you run several copies of that same program behind a load balancer.

This is how most applications start, and for good reason. Everything is in one place, so the code is easy to run on your laptop, easy to test end to end, and easy to reason about because a single request travels through one program you can step through. The monolith gets a bad reputation, but a huge number of successful products run happily as one well organized codebase for years.

As applications and teams grew, deploying one large application for every change became increasingly painful. Developers started looking for ways to split large systems into smaller, independently deployable pieces.

What microservices actually look like#

Now take that same store and split it into smaller, independent pieces. Users become one service. Products become another. Cart, orders, and payments each become their own service, deployed independently and often backed by their own database.

                      network calls
    ┌───────────┬───────────┬──────────┬────────────┐
    │           │           │          │            │
┌───┴───┐  ┌────┴─────┐  ┌──┴───┐  ┌───┴────┐  ┌────┴─────┐
│ Users │  │ Products │  │ Cart │  │ Orders │  │ Payments │
└───┬───┘  └────┬─────┘  └──┬───┘  └───┬────┘  └────┬─────┘
    ↓           ↓           ↓          ↓            ↓
  own db      own db      own db     own db       own db

The features are the same, but the wiring changed completely. When the cart needs a product price, it no longer makes a function call. It makes a network request to the products service and waits for a response over HTTP or a message queue. When orders needs to know who a user is, it asks the users service instead of joining a table.

The biggest advantage is independence. The payments team can deploy a fix at 2pm without touching the catalog. If checkout traffic spikes, you can run twenty copies of the orders service while leaving everything else at one copy each.

                  Before

  ┌──────────┐   ┌──────────┐   ┌──────────┐
  │  Orders  │   │ Products │   │ Payments │
  └──────────┘   └──────────┘   └──────────┘
       ×1             ×1             ×1


           Checkout traffic spikes

  ┌──────────┐   ┌──────────┐   ┌──────────┐
  │  Orders  │   │ Products │   │ Payments │
  ├──────────┤   └──────────┘   └──────────┘
  │  Orders  │        ×1             ×1
  ├──────────┤
  │  Orders  │   only the service under load
  ├──────────┤   scales, the rest stay at ×1
  │  Orders  │
  ├──────────┤
  │  Orders  │
  └──────────┘
       ×5

Interestingly, software often ends up reflecting the way teams are organized, an observation known as Conway's Law.

Conway's Law: Organizations design systems that mirror the way they communicate.

Melvin Conway, 1967

A company with separate payments, catalog, and orders teams will often build separate services for those areas too.

Teams can even choose different languages or databases per service, because the only contract between them is the network interface they agree on. That contract is also a boundary, which means each service has to decide how much it believes what the others tell it, in the same way a server can never trust your browser just because the request looks well formed.

Before we go deeper, it helps to see the two approaches side by side. This is the same story the rest of the article tells, condensed into a single view.

The part that confused me most#

For a long time, I thought "monolith" was just a polite word for messy code and "microservices" meant clean, well-designed software. I also thought that if you split an application into separate projects or folders, such as client, server, db, and shared, you had somehow built microservices.

Both ideas are wrong.

A monolith can be beautifully organized, with clear internal modules that barely know about each other. People often call this a modular monolith. It gives you much of the structure people associate with microservices while still deploying as a single application.

The opposite is also true. Microservices can be an absolute mess. If changing one service forces you to redeploy three others every time, you haven't really gained the independence microservices are supposed to provide. You've simply built a distributed monolith.

So what's the mental rule?

Microservices aren't about how many repos or modules you have. They're about how many applications you deploy independently.

Everything else is just how you organize your code.

Once that clicked for me, the whole discussion became much simpler. Code organization and deployment are two different concerns. You can have clean or messy code in either architecture.

A real-world comparison#

So far we've looked at the structure of each architecture. Now let's see how that affects everyday development.

Imagine your product manager asks for a new feature: support for discount codes at checkout.

Monolith version

In a monolith, adding the feature is straightforward. You create a discounts module, store the discount codes in the application's database, and have the orders code call it when calculating the total.

Because everything runs inside the same application, you can test the entire checkout flow on your machine. When you're ready, you deploy the application once, and the feature is available everywhere.

Microservices version

In a microservices architecture, the change is usually larger. You might create a new discounts service with its own database and deploy it independently. During checkout, the orders service now has to call the discounts service over the network to calculate the final price. That immediately raises new questions. What happens if the discounts service is slow? What if it is temporarily unavailable? Should the order continue without the discount, or should checkout fail?

Testing also changes. Instead of running one application, you now need several services working together. On the other hand, the discounts service can evolve independently. The team responsible for discounts can deploy improvements without coordinating a release of the rest of the application.

Neither approach is inherently better. The monolith makes the feature easier to build. Microservices make it easier to own, evolve, and deploy independently. That's the trade-off in its simplest form.

The price of independence#

Microservices are not a free upgrade. The independence they give you comes with extra complexity.

Inside a monolith, one part of the application talks to another through a simple function call. It is fast and rarely fails. In a microservices architecture, that same communication happens over the network. Network requests can be slow, fail completely, or return unexpected errors, so every service has to be prepared for those situations.

Data becomes more complicated too. In a monolith, everything usually lives in one database, so updating related information is straightforward. In a microservices architecture, each service often has its own database. Keeping data consistent across several independent systems is much harder.

Debugging also changes. Instead of following a request through one application, you now have to trace it across several services. That's why teams using microservices rely heavily on logging, monitoring, and distributed tracing to understand what is happening.

None of this means microservices are a bad idea. It simply means that the independence they provide comes at a cost. If that independence solves problems your team actually has, the extra complexity is worth it. If not, a monolith is often the simpler and better choice.

Monolith or microservices: which should you choose?#

For most new applications, a modular monolith is the sensible starting point. It lets you focus on building the product instead of managing infrastructure. Development, testing, and deployment stay simple, and if you keep the code well organized, you can still split parts of the application later if the need arises.

Microservices start to make sense when one deployable application is no longer enough. That usually happens because of growth rather than technology. Multiple teams need to release independently, different parts of the system have very different scaling requirements, or a particular service needs to be isolated for reliability.

In other words, the signal isn't that your monolith feels old. The signal is that your organization or your application has outgrown a single deployment.

That's why many successful systems follow the same path. They start as a monolith, learn where the natural boundaries are, and only then split out the parts that genuinely benefit from becoming independent services. Starting with dozens of microservices before you have that pressure often gives you the costs long before you see the benefits.

Beyond monoliths and microservices#

Monoliths and microservices are the two architectures you'll hear about most often, but they aren't the only options. As systems grow, developers have come up with other ways of splitting applications and communicating between them.

Serverless. Instead of running long-lived services, you deploy small functions that run only when they are needed. Platforms such as AWS Lambda and Cloudflare Workers start them on demand, scale them automatically, and stop them when they are no longer needed.

Event-Driven Architecture. Instead of one service calling another directly over HTTP, services communicate by publishing and receiving events. A payment might publish an "Order Paid" event, and other services react to it whenever they need to.

Although they look different, they all explore the same basic idea: how should an application be split into independent pieces, and how should those pieces communicate?

Key takeaways#

• The real difference between a monolith and microservices is the number of independently deployable units, not the quality of the code.
• A monolith ships as one program with usually one database, which keeps development, testing, and reasoning simple.
• Microservices split an application into many small programs that deploy independently and talk over the network, trading simplicity for independence.

Frequently asked questions#

What is the main difference between a monolith and microservices?#

A monolith is one application that you build and deploy as a single unit, while microservices split that same application into many small services that deploy independently and talk over the network. Everything else, including how you organize the code, follows from that one difference.

Is a monolith bad or outdated?#

No. A monolith is simply one deployable unit, and plenty of large, successful products run as well organized monoliths.

Are microservices always more scalable?#

Not automatically. Microservices let you scale individual pieces independently, which helps when different parts have very different load. But you can also scale a monolith by running more copies of it.

What is a modular monolith?#

A modular monolith is simply a monolith with clear internal boundaries between features. The code is organized into separate modules, but everything is still built and deployed as a single application.

For example, a project might be organized like this:

my-app/
│
├── src/
│   ├── users/
│   ├── products/
│   ├── orders/
│   ├── payments/
│   └── shared/
│
├── database/
├── tests/
└── package.json

Even though the code is split into well-defined modules, this is still a monolith because the entire application is built and deployed together. You get much of the organization people associate with microservices without the cost of distributing everything across the network.

Should a new project start with microservices?#

Usually not. Most new projects are better off as a monolith, ideally a modular one, because you rarely know the right service boundaries up front. It is common and healthy to start with a monolith and split out services later, once real scaling or team pressure shows you where the seams are.

How do microservices talk to each other?#

Over the network, most often through HTTP APIs or a message queue, instead of the direct function calls a monolith uses internally. That network hop is exactly what gives services their independence, and also what introduces the extra latency and failure cases you have to plan for.

The mental model to remember#

Monoliths and microservices are not rival teams you have to pick a side on. They are two different ways of building the same application, and the right choice depends on your scale, your team, and the problems you actually have today, not the ones you might have someday.

Once you stop thinking in terms of "good" and "bad" and start thinking in terms of deployments, the whole discussion becomes much simpler. You can look at your own system, decide how much independence each part really needs, weigh that against the extra complexity, and make the decision on its merits.

If you remember just one thing from this article, let it be this:

A monolith is one independently deployable application. Microservices are many independently deployable applications that communicate over the network.

Everything else is just a consequence of that one design choice.

For most of the web's history, that wasn't possible.

In the earlier articles in this series, we followed how the web became interactive. We saw how Javascript brought code into the browser, how jQuery smoothed over the differences between browsers, how Single-Page Applications kept users on one continuous page, and how React made large, state-driven interfaces manageable.

Every one of those steps happened inside the browser. Node.js is the moment Javascript finally escaped it.

Javascript was trapped in the browser#

When Javascript was created, it was designed for one place: the browser. It could respond to clicks, validate forms, and update the page, but it had no way to read a file, talk to a database, or listen for network requests. Those abilities belonged to the server, and the server spoke a different language entirely.

So web developers lived a double life. On the front end they wrote Javascript. On the back end they wrote PHP, Ruby, Python, or Java. A single feature often meant switching between two languages, two sets of tools, and two ways of thinking about the same problem.

At first glance, splitting an application along language lines can look like a clean separation. The boundary between the front end and the back end is obvious, and each side owns its own tools and conventions without stepping on the other. That tidiness was real, but it came with costs that were just as real.

Form validation was the clearest example. It frequently had to be written twice, once in Javascript for instant feedback in the browser and again in the server's language so the data could actually be trusted. Knowledge didn't transfer cleanly between the two halves either. A strong front-end developer wasn't automatically useful on the back end, and the reverse was just as true.

So why couldn't the browser's language run on the server too?

Why couldn't Javascript run on a server?#

Inside a browser, Javascript worked because the browser included everything it needed. It contained software that could read and execute Javascript code, and it provided built-in features for working with web pages, forms, buttons, and user interactions.

A server is a completely different environment. It doesn't display web pages or respond to button clicks. Instead, it needs to read files, accept network requests, connect to databases, and communicate with the operating system.

The problem was that servers didn't include software that could execute Javascript, nor did they provide the tools Javascript needed to perform server-side tasks. Without those two pieces, Javascript simply couldn't run on a server.

That finally changed because of the browser wars.

Two things had to happen first#

The first breakthrough came from Google.

In 2008, Google released Chrome with a new Javascript engine called V8. A Javascript engine is the software that reads and executes Javascript code. Every browser has one, although they use different engines. Chrome uses V8, Firefox uses SpiderMonkey, and Safari uses JavaScriptCore.

V8 was much faster than the engines used by older browsers, allowing websites to become faster and more interactive.

In 2008, V8 is introduced

Although V8 was created for Chrome, it wasn't tied to Chrome itself. It was a standalone Javascript engine that could be embedded into other applications. That meant there was no technical reason it had to stay inside a browser.

Javascript could now run in both the browser and on a server.

The second breakthrough came a year later. Ryan Dahl realized that if he took V8 out of the browser and combined it with the tools a server needs, Javascript could finally run on the server too.

                Javascript
                    ↓
                V8 Engine
             ┌──────┴──────┐
             ↓             ↓
      Browser APIs    Node.js APIs
   (DOM, Forms...)  (Files, Network, OS)

Node.js is born#

In 2009, Ryan Dahl turned that idea into reality by introducing Node.js.

He took Google's V8 engine and combined it with APIs for reading files, handling network connections, and communicating with the operating system. For the first time, Javascript had everything it needed to run as a server language.

Suddenly Javascript could do the things that had always been reserved for server languages. It could read and write files, listen for incoming requests on a port, and respond to them. A language that had spent its whole life reacting to button clicks could now run a web server.

But giving Javascript access to the operating system wasn't the part that made Node.js revolutionary. It also introduced a different way of handling many connections at the same time, and that idea is what really set it apart.

The real innovation: not blocking#

Giving Javascript access to the server was only part of the story. What really made Node.js stand out was the way it handled many requests at the same time.

Imagine one thousand people opening your website at once. Every request might need to read a file, query a database, or call another service. The problem is that those operations take time. While the server is waiting for the result, it still has hundreds or thousands of other requests to deal with.

At the time, many popular web servers handled this by assigning each request its own thread or process. That way, while one request was waiting, another could continue running. It was a proven approach and worked well, but it also meant that busy servers had to manage hundreds or even thousands of threads at the same time.

Ryan Dahl believed there was another option.

Instead of creating a thread for every request, Node.js uses a single main thread to coordinate the work. When it starts a slow operation, such as reading a file or querying a database, it doesn't stop and wait. Instead, it lets that operation continue in the background and immediately starts working on another request. When the result is ready, Node.js comes back and finishes the original task.

This idea, known as non-blocking I/O, wasn't invented by Node.js. Similar approaches already existed in other software. What Node.js did was bring this model to Javascript in a simple runtime that made it easy for web developers to build highly scalable servers.

It helps to picture a good waiter in a busy restaurant. A blocking waiter takes one table's order, walks to the kitchen, and waits there until the food is ready before serving anyone else. A non-blocking waiter hands the order to the kitchen and immediately starts serving other tables. When the food is ready, they come back and deliver it.

This made Node.js especially good for applications that spend much of their time waiting, such as web APIs, chat applications, and streaming services. It was less suited to CPU-intensive work, where long calculations could occupy the main thread, but for the kind of work most web applications perform, it was an excellent fit.

The way Node.js handled requests made it an excellent choice for many web applications. But its biggest impact wasn't technical. It changed the way developers built software.

One language across the whole stack#

The moment Javascript could run on the server, the double life ended.

Developers could now build an entire application, from front end to back end, using a single language. Validation logic could be shared instead of rewritten. Knowledge gained on one side of the application carried over to the other, making it easier for developers to move across the entire stack.

Server-side rendering also became much more natural. The same code that described a user interface in the browser could now run on the server to generate the initial HTML, an idea that modern frameworks such as Next.js build upon.

Running Javascript on the server solved one problem. Making it easy to build and share software solved another.

npm and an explosion of tooling#

Node.js arrived with a companion that turned out to be just as important: npm, its package manager.

npm made sharing and installing reusable pieces of code effortless. Need a library for dates, testing, or talking to a database? A single command installed it. This simplicity helped npm grow into the largest software registry in the world, and its ecosystem became one of Node.js's greatest strengths.

There's another consequence that's easy to miss. Even front-end developers who never build a Node.js server rely on it every day. Modern build tools such as Vite, Webpack, Babel, ESLint, and countless others run on Node.js. It quietly became the foundation of the modern Javascript ecosystem, whether or not your application ever uses Node.js in production.

The trade-offs we still live with#

Like every technology we've covered in this series, Node.js solved important problems but introduced new ones of its own.

The ease of installing packages led to deep dependency trees, where even a small project can quietly pull in hundreds of packages. The ecosystem also moves quickly, and keeping up with changing tools can be exhausting. Finally, while Node.js excels at input and output heavy workloads, applications with long-running CPU-intensive tasks require extra care because they can block the main thread.

Even with those trade-offs, Node.js changed web development in a way no previous technology had. It turned Javascript into a full-stack language, allowing developers to use the same language from the browser all the way to the server.

Key takeaways#

• For its first years, Javascript could only run inside the browser, which forced web developers to use a separate language on the server.
• Google's V8 engine made it possible to run Javascript efficiently outside the browser, and Node.js added the server capabilities it needed.
• Node.js popularized a non-blocking, event-driven model that handles many simultaneous connections efficiently.
• With Node.js and npm, Javascript became a full-stack language and the foundation of modern web tooling.

Frequently asked questions#

Is Node.js a programming language?#

No. Node.js is a runtime for Javascript. It uses Google's V8 engine to execute Javascript code and provides the APIs needed to work with files, networks, and the operating system.

Is Node.js a framework?#

No. Node.js is the environment your Javascript runs in, not a framework for structuring an application. Frameworks such as Express or Next.js are built on top of Node.js to make certain kinds of applications easier to build.

Why did Node.js become so popular?#

It let developers use a single language across the entire stack, it handled input and output heavy workloads efficiently, and it came with npm, an enormous ecosystem of reusable packages. Together those made it a natural default for modern web development.

Is Node.js good for heavy calculations?#

Not especially. Because your code runs on a single main thread, long-running calculations can block everything else. Node.js shines at work that spends its time waiting on other systems, such as serving APIs or handling real-time connections.

Does Node.js replace Javascript in the browser?#

No. Browsers still run Javascript exactly as before. Node.js simply lets the same language run on the server as well, allowing developers to build entire applications with Javascript from front end to back end.

Explore the series#

I wasn't building websites when the web was just HTML or when Javascript didn't exist. Like many developers, I learned modern frameworks first and only later became curious about how we got here.

This series is my way of connecting those dots. By looking back at the problems developers faced and the solutions they created, it becomes much easier to understand why today's tools exist and why the web evolved the way it did.

• Why we needed Javascript
• Why we needed jQuery
• Why we needed Single-Page Applications (SPAs)
• Why we needed React
• Why we needed Node.js (You're reading this)

That's the end... for now#

This is where our journey through the evolution of modern web development pauses, but it isn't over.

We've followed the web from static HTML pages to interactive applications, from handwritten DOM manipulation to React, and finally to the moment Javascript escaped the browser and became a full-stack language with Node.js.

There are still many stories left to tell. Technologies such as TypeScript, Babel, Webpack, Vite, Docker, and many others solved their own problems and changed the way we build software. Those are chapters for another day.

Until then, I hope this series helped answer a question that many developers never stop to ask:

Why do these technologies exist in the first place?

Because once you understand the problems they were created to solve, today's tools make a lot more sense.

But React wasn't created because developers wanted another Javascript library. It was created because the web had reached a point where existing approaches no longer scaled.

In the previous articles in this series, we explored how the web evolved. We saw how Javascript transformed static web pages into interactive experiences, how jQuery simplified DOM manipulation and browser compatibility, and how Single-Page Applications (SPAs) made websites feel more like desktop applications.

Each of these technologies solved an important problem. In doing so, they also made it possible to build larger and more sophisticated applications.

As those applications grew, a new challenge emerged.

Developers no longer struggled to make pages interactive. They struggled to keep increasingly complex user interfaces predictable, consistent and easy to maintain.

React was created to solve that challenge.

The problem wasn't updating the DOM#

One of the biggest misconceptions about React is that it was created because updating the DOM was slow. That wasn't the real problem.

Libraries like jQuery had already made DOM manipulation straightforward.

$("#username").text("Duke");
$("#login-button").hide();
$(".notification").addClass("success");

Updating an element was easy. The difficult part was knowing which elements needed to be updated after the application's state changed.

As web applications grew, different parts of the interface also started sharing the same data. A user's profile information could appear in the navigation bar, account menu, comments, chat messages and activity feed all at once.

User updates profile
        ↓
Application state changes
        ↓
→ Navigation bar
→ Account menu
→ Comments
→ Chat
→ Activity feed

Keeping all of these views synchronized became increasingly difficult. Before React, developers had to manually update every affected part of the interface whenever the application's state changed. This approach worked for small websites, but as applications grew, it became one of the biggest sources of bugs.

Updating one element was easy.

Updating every element that depended on the same data wasn't.

State became the real challenge#

But what had changed? Why did keeping the interface synchronized become so difficult?

Because modern web applications had to manage far more state than traditional websites ever did.

A page no longer displayed static content. It had to remember whether a user was logged in, what products were in their shopping cart, which notifications had been read and what information had already been entered into a form.

Instead of rebuilding the page after every request, applications remained active and continuously responded to user input. Every change to that state had to be reflected everywhere the data was being displayed.

The more state an application managed, the harder it became to keep the entire interface synchronized.

React introduced a different way of thinking#

Instead of telling the browser exactly how to update the page, React asked developers to describe what the interface should look like for the current application state.

When that state changed, React compared the new UI with the previous one and applied the DOM updates needed to reflect the change.

Instead of writing code like:

Find this element.
Change its text.
Hide this button.
Show that message.
Update this counter.

Developers could simply think:

Current application state
        ↓
What should the user see?

This shifted the focus from manually updating the interface to describing the desired result. React handled the process of keeping the DOM synchronized, an approach known as declarative programming.

Rather than changing how developers manipulated the DOM, React changed how they thought about building user interfaces.

This may sound like a subtle difference, but it fundamentally changed how developers built applications.

Instead of manually updating every affected part of the page, developers described how each component should render for a given application state. React then handled translating those changes into the necessary DOM updates.

This reduced the amount of manual synchronization developers had to write, making large applications easier to build and maintain.

Components made large applications easier to manage#

React also encouraged developers to split user interfaces into small, reusable components. Instead of treating an entire page as one large block of HTML and Javascript, each part of the interface became an independent building block with its own responsibility.

For example, an online store might be structured like this:

<App>
 ├── <Navbar />
 ├── <SearchBar />
 ├── <ProductList />
 │      └── <ProductCard />
 ├── <ShoppingCart />
 └── <Footer />

Each component described one part of the interface and could be developed, tested and maintained independently. Components could also be reused across different pages, reducing duplication and making future changes much easier.

This approach made large applications easier to understand. Rather than navigating a single file containing thousands of lines of code, developers could focus on one component at a time.

The Virtual DOM wasn't the main innovation#

This new way of building user interfaces raised an obvious question: how could React update the page efficiently without developers manually manipulating the DOM?

Much of the early discussion focused on the Virtual DOM. Many developers assumed this was the reason React became so successful because it appeared to solve one of the web's biggest performance concerns: avoiding unnecessary DOM updates.

The Virtual DOM was an important optimization, but it wasn't React's biggest innovation.

React's real innovation was its programming model. Developers described how the UI should look for a given application state, while React handled the process of comparing the new UI with the previous one and applying only the DOM changes that were actually needed.

The Virtual DOM was simply the mechanism that made this approach efficient. Even without it, the idea of building interfaces declaratively and organizing them into components would still have fundamentally changed front-end development.

React changed front-end development#

React didn't just introduce a new API or a faster way to update the DOM. It popularized a different way of building front-end applications.

Concepts like components, declarative rendering and state-driven user interfaces became the foundation of modern front-end development. Today, frameworks such as Vue, Svelte, Solid and even newer versions of Angular embrace many of the same ideas, even though they implement them differently.

React also influenced the wider ecosystem. State management libraries, routing solutions, testing tools and design systems were all built around the component model, making it easier to develop large applications as teams and codebases grew.

Today, thinking in components and describing the UI as a function of state feels completely natural.

Before React, it wasn't.

So why did we need React?#

React wasn't created because developers needed another Javascript library.

It was created because web applications had become too complex to manage through manual DOM updates alone.

By introducing a declarative, component-based approach, React made large, state-driven applications easier to build, understand and maintain. The Virtual DOM helped make this practical, but it was the programming model that changed how developers thought about user interfaces.

Today, those ideas have become the standard across modern front-end development.

React was the next step in the web's evolution.

Common misconceptions#

React replaced Javascript#

No. React is a Javascript library.

Every React application is still written using Javascript (or Typescript).

React made the DOM fast#

Not exactly. Manipulating the DOM wasn't the biggest challenge.

Managing increasingly complex user interfaces was.

React's biggest innovation was providing a better way to describe and organize those interfaces.

React invented components#

No.

Component-based development had existed for many years in technologies such as Java Swing and Microsoft's .NET frameworks.

However, React popularized the idea and made it practical for large-scale web applications.

You must use React to build modern websites#

No. Many websites don't need React at all.

Traditional server-rendered applications are often simpler, faster and easier to maintain.

React is most valuable when building highly interactive applications with lots of shared state.

React replaced jQuery overnight#

Not at all. For many years, both libraries coexisted.

Many applications even used jQuery alongside React during gradual migrations.

React didn't make jQuery obsolete overnight. It addressed a different set of problems as web applications became increasingly complex.

Frequently asked questions#

Did React replace Javascript?#

No.

React is a Javascript library, not a replacement for the language itself. Every React application is still written using Javascript (or Typescript), and understanding Javascript fundamentals is essential for using React effectively.

In fact, React builds upon Javascript features such as functions, objects, modules and closures rather than replacing them.

Is React a framework?#

Not officially.

React describes itself as a Javascript library for building user interfaces. Its primary responsibility is rendering the UI based on your application's state.

Unlike full frameworks, React doesn't include built-in solutions for routing, state management or data fetching. Developers typically choose those tools separately, although modern frameworks like Next.js build on top of React to provide a more complete development experience.

Does React make websites faster?#

Not necessarily.

React wasn't created because websites were slow.

It was created because building and maintaining complex user interfaces had become difficult.

In some cases React can improve performance by updating only the parts of the page that have changed. In other cases, a simple server-rendered website with little Javascript may actually load faster than a React application.

The biggest benefit of React is improving the developer experience and making large applications easier to maintain.

Why did React become so popular?#

React solved a problem that many developers were experiencing.

As applications became larger, manually keeping the UI synchronized became increasingly difficult. React introduced a simpler mental model: describe what the interface should look like for the current application state, and let React handle updating the DOM.

Its component-based architecture, strong ecosystem and backing from Facebook also contributed to its rapid adoption.

Today, many of the ideas React popularized have influenced nearly every modern front-end framework.

Is React still relevant today?#

Yes.

React remains one of the most widely used libraries for building modern web applications, powering products used by millions of people every day.

The ecosystem has evolved significantly since React was first released. Features such as Hooks, Server Components and modern frameworks like Next.js have changed how React applications are built.

Even if another framework eventually becomes more popular, React's lasting impact isn't tied to its market share.

It changed how developers think about building user interfaces. Concepts such as declarative rendering, reusable components and state-driven interfaces have become standard practices across modern front-end development.

Explore the series#

I wasn't building websites when the web was just HTML or when Javascript didn't exist. Like many developers, I learned modern frameworks first and only later became curious about how we got here.

This series is my way of connecting those dots. By looking back at the problems developers faced and the solutions they created, it becomes much easier to understand why today's tools exist and why the web evolved the way it did.

• Why we needed Javascript
• Why we needed jQuery
• Why we needed Single-Page Applications (SPAs)
• Why we needed React (You're reading this)
• Why we needed Node.js

We started with a web made entirely of static HTML pages. To create pages dynamically, servers began generating HTML on demand using technologies such as CGI.

That solved one problem, but browsers were still passive. Every interaction required a trip back to the server. That's why Javascript was created, allowing browsers to run code and respond immediately to user actions.

Later, AJAX made another major leap forward by allowing browsers to communicate with servers in the background, updating parts of a page without requiring a full page reload. We also saw how jQuery made that new way of building websites much easier by hiding browser differences behind a simple, consistent API.

Even then, one limitation remained.

Although parts of a page could now update independently, navigating to another page still meant downloading an entirely new HTML document and rebuilding the interface from scratch.

That limitation led to the next major evolution of the web: the Single-Page Application (SPA), a new architecture that kept the browser on the same page while Javascript updated the interface.

Confession: When I first heard the term Single-Page Application, I assumed it literally meant a website made from a single HTML page. Technically... that's not completely wrong, but it's also missing the point.

The "single page" isn't about cramming your entire application into one enormous HTML file. It's about the browser staying on the same page while Javascript updates the interface as you navigate.

If you were expecting one gigantic index.html containing your entire application... you're definitely not the only one.

The page reload problem#

When the web was originally designed, websites were exactly what the name suggested: pages.

Each click usually triggered a familiar sequence of events.

User clicks a link
        ↓
Browser requests a new page
        ↓
Server returns an HTML document
        ↓
Browser replaces the current page
        ↓
Everything loads again

For years, this was completely normal.

Reading a blog, browsing documentation, or shopping online didn't require a highly interactive interface. Waiting for the next page to load was simply how the web worked.

However, expectations began to change.

As web applications became more capable, users' expectations changed too.

People wanted to open a menu, switch between messages, browse products, or move between different sections of an application without seeing the entire page disappear and reload each time.

The traditional request-response model started to feel increasingly slow and disruptive.

Why AJAX wasn't enough#

AJAX was a huge step forward. Instead of refreshing the entire page, browsers could request only the data they needed and update a small part of the interface. Search suggestions could appear as you typed, shopping carts could update instantly, new chat messages could arrive automatically, and comments could be posted without interrupting what you were reading.

But AJAX solved only part of the problem. It improved individual interactions without changing how websites were fundamentally built. Each page was still a separate HTML document served by the server.

In a traditional Multi-Page Application (MPA), clicking a navigation link typically requested a completely new HTML document. The browser discarded the current page, downloaded a new one, reloaded the application's Javascript and CSS, and started everything again from scratch.

Developers had made websites far more interactive, but the web was still built around navigating from one page to another. As users began expecting web applications to behave more like desktop software, that traditional page-by-page model started to show its age.

Single-Page Applications arrive#

A Single-Page Application (SPA) can contain dozens or even hundreds of different screens. The "single page" refers to the browser loading one HTML document initially, while Javascript takes over navigation using client-side routing and updates the interface without performing a full page reload.

Instead of requesting a new page for every navigation, the browser keeps the application running and asks the server only for the data it needs. That matters because a full page load is never free, and the traditional model paid that cost again on every single click.

The difference is easier to understand visually.

# Traditional Multi-Page Application (MPA)

Click
   ↓
Server returns a new HTML page
   ↓
Browser replaces everything

---

# Single-Page Application (SPA)

Application is already loaded
          ↓
User clicks a link
          ↓
Javascript updates the interface
          ↓
Server returns only the required data (if needed)

From the user's perspective, the experience became dramatically smoother. Navigation felt almost instant, animations remained uninterrupted, and the application could preserve its state while moving between different screens.

For the first time, websites no longer behaved like a collection of separate pages. They felt like a single, continuous application running inside the browser.

This architectural shift paved the way for frameworks such as React, Angular, and Vue, which embraced this new model and made it practical to build increasingly complex web applications.

The trade-offs#

Like every major shift in web development, Single-Page Applications solved one set of problems while introducing new ones.

Because much more of the application now lived in the browser, the initial download often became significantly larger. Instead of receiving a small HTML page for each request, users typically downloaded a large Javascript bundle before the application became fully interactive.

Building SPAs also increased complexity for developers. Client-side routing, state management, authentication, browser history, and data synchronization all became responsibilities of the application instead of the server. Moving those concerns into the browser is a user experience win, but it's worth being clear that it moves the code without moving the security, because a server can never trust your browser no matter how much of the application now runs there.

Search engine optimization (SEO) was another challenge in the early days of SPAs. Many applications initially sent the browser a nearly empty HTML document containing little more than a root element, with Javascript responsible for fetching data and rendering the entire interface afterwards.

Early search engines often indexed only that initial HTML, meaning they couldn't reliably see the content users eventually saw in their browsers. As a result, some SPA websites struggled to appear in search results.

Over time, both search engines and web frameworks improved. Techniques such as Server-Side Rendering (SSR) and Static Site Generation (SSG) made it possible to send fully rendered HTML from the start, allowing search engines to crawl and index pages much more reliably.

What came after single-page applications?#

Single-Page Applications changed how websites were built, but they didn't solve every problem.

As applications grew larger, managing hundreds of components, events, and DOM updates with libraries like jQuery became increasingly difficult. Codebases became harder to organize, maintain, and reason about. Avoiding page reloads was no longer the biggest challenge. Building and maintaining large client-side applications was.

That challenge led to the rise of modern frontend frameworks, beginning with React, which introduced a new way of thinking about building user interfaces.

Key takeaways#

• Single-Page Applications changed the web by loading a single HTML document and updating the interface with Javascript instead of reloading entire pages.
• While AJAX made individual interactions more dynamic, SPAs rethought the overall architecture of web applications.
• The complexity of building large SPAs eventually led to the development of frameworks like React, which provided better ways to organize and manage growing applications.

Frequently asked questions#

What is a Single-Page Application?#

A Single-Page Application (SPA) is a web application that loads a single HTML document initially and uses Javascript to update the interface as users interact with it. Instead of requesting a new page for every navigation, the browser updates the existing page and fetches only the data it needs.

Are SPAs still popular?#

Yes. Single-Page Applications are still widely used for applications where users spend a lot of time interacting with the interface, such as email clients, project management tools, messaging applications, dashboards, and online editors. Although developers now have more architectural choices, the SPA model continues to power many modern web applications.

Can Single-Page Applications be SEO friendly?#

Not necessarily. Early SPAs often struggled with SEO because search engines had difficulty indexing content rendered entirely with Javascript. Today, frameworks like Next.js support server-side rendering and static site generation, allowing developers to build SPA-like experiences while maintaining excellent SEO.

Is React a Single-Page Application?#

No. React is a Javascript library for building user interfaces, not an application architecture.

However, React is commonly used to build Single-Page Applications, which is why the two concepts are often associated. React can also be used to build server-rendered websites, static sites, or individual interactive components within traditional multi-page applications.

Explore the series#

I wasn't building websites when the web was just HTML or when Javascript didn't exist. Like many developers, I learned modern frameworks first and only later became curious about how we got here.

This series is my way of connecting those dots. By looking back at the problems developers faced and the solutions they created, it becomes much easier to understand why today's tools exist and why the web evolved the way it did.

• Why we needed Javascript
• Why we needed jQuery
• Why we needed Single-Page Applications (SPAs) (You're reading this)
• Why we needed React
• Why we needed Node.js

That solved one of the web's biggest limitations, but it also exposed a new problem.

As developers started building richer websites, they discovered that the same Javascript code often behaved differently across browsers. Writing Javascript had become possible. Writing Javascript that worked everywhere was another challenge entirely.

The problem: browsers didn't agree#

The late 1990s and early 2000s were an exciting time for the web. Javascript was becoming more popular, websites were growing increasingly interactive, and browsers were competing aggressively for users.

Unfortunately, they weren't always competing in the same direction.

There wasn't yet a fully consistent standard for how browsers should behave. Internet Explorer, Netscape Navigator, Opera, Safari, and later Firefox often introduced their own APIs, features, and quirks.

As a result, developers frequently discovered that code working perfectly in one browser would fail in another.

For example, attaching a click event wasn't always done the same way.

// Internet Explorer
element.attachEvent("onclick", handler);

// Most other browsers
element.addEventListener("click", handler);

Even selecting elements, handling events, or reading CSS properties could require different code depending on the browser.

Supporting all of those browsers quickly became exhausting. Projects filled with browser-specific conditions, compatibility fixes, and workarounds, leaving developers spending as much time fighting browser inconsistencies as building new features.

The larger an application became, the harder those differences were to maintain.

Developers needed a better solution.

jQuery arrives#

In 2006, John Resig introduced jQuery with a simple goal:

Write less, do more.

Instead of forcing developers to remember dozens of browser differences, jQuery provided a simple, consistent API that worked across all major browsers, making cross-browser development dramatically easier.

It didn't replace Javascript. Instead, it provided a simpler and more consistent way to work with it.

Conceptually, jQuery sat between your code and the browser, hiding many of the differences between browser implementations.

        Your code
            ↓
          jQuery
   ┌────────┼────────┐
   ↓        ↓        ↓
   IE    Firefox   Safari

Much of that convenience came from simplifying DOM manipulation, event handling, animations, and AJAX into a small, consistent set of functions.

Let's look at what that meant in practice.

One of the biggest reasons developers embraced jQuery was how much simpler common tasks became.

Before jQuery#

Selecting an element:

document.getElementById("menu");

Adding a click event:

document.getElementById("button").addEventListener("click", function () {
    alert("Clicked!");
});

After jQuery#

Selecting an element:

$("#menu");

Adding a click event:

$("#button").click(function () {
  alert("Clicked!");
});

The difference looks small in these examples, but across hundreds or thousands of lines of code, the productivity gains quickly added up.

The shorter syntax made code easier to read, but jQuery's biggest advantage wasn't saving a few keystrokes.

By hiding browser-specific differences behind a consistent API, developers could write code once and spend far less time debugging compatibility issues.

Plugins changed everything#

As jQuery grew in popularity, it became much more than a compatibility library.

Need form validation? There was a plugin.

Need a date picker? There was a plugin.

Need a carousel, lightbox, drag-and-drop interface, or animation? There was a plugin.

An enormous ecosystem grew around jQuery, allowing developers to add sophisticated functionality with only a few lines of code instead of building everything from scratch.

Combined with excellent documentation and a vibrant community, jQuery quickly became one of the most influential libraries in the history of web development.

At its peak, it powered the vast majority of websites on the internet, making it almost impossible to build for the web without encountering jQuery.

Why did jQuery decline?#

Ironically, jQuery became so successful that browsers eventually adopted many of the APIs and patterns developers had come to rely on.

Modern browsers became far more consistent, while Javascript and the browser platform continued to evolve.

Many of the conveniences that once made jQuery essential became part of the web itself. Features such as querySelector(), fetch(), classList, and improved event handling allowed developers to write simpler, cross-browser code without relying on a library.

At the same time, frameworks such as React, Angular, and Vue emerged, solving problems that jQuery had never been designed to address, such as building and managing large, interactive applications.

Today, jQuery remains an important part of web history. It solved a real problem at exactly the right time and helped shape the modern web, even if many of its original responsibilities are now handled directly by browsers and modern Javascript.

Key takeaways#

• jQuery solved one of the biggest challenges of early web development by providing a consistent API across browsers, allowing developers to write less compatibility code.
• Its plugin ecosystem and simple syntax dramatically accelerated development, making jQuery one of the most influential libraries in web history.
• As browsers standardized and Javascript evolved, many of jQuery's core features became built into the web platform, paving the way for modern frameworks to solve a new generation of problems.

Frequently asked questions#

Was jQuery a programming language?#

No. jQuery is a Javascript library, not a programming language. It provides a collection of functions that make common Javascript tasks easier and more consistent across different browsers.

Is jQuery still used?#

Yes. Although many new projects no longer depend on it, jQuery is still used by millions of websites, especially older applications and content management systems like WordPress. It also continues to be actively maintained.

Should you learn jQuery today?#

If you're learning web development, focus on modern Javascript first. Today's browsers support many features that once required jQuery, and modern frameworks often don't rely on it. However, understanding jQuery is still valuable if you maintain legacy applications, work with existing codebases, or develop for platforms that still use it.

Does WordPress still use jQuery?#

Yes. WordPress still includes jQuery, and many themes and plugins rely on it for interactive features such as sliders, menus, form validation, and pop-ups.

That said, modern WordPress development is gradually moving away from jQuery. The Block Editor (Gutenberg) is built with React, and many new themes and plugins now prefer modern Javascript APIs instead of depending on jQuery.

If you're maintaining an existing WordPress site, you'll almost certainly encounter jQuery. However, if you're building new functionality today, modern Javascript is generally the recommended approach.

Explore the series#

I wasn't building websites when the web was just HTML or when Javascript didn't exist. Like many developers, I learned modern frameworks first and only later became curious about how we got here.

This series is my way of connecting those dots. By looking back at the problems developers faced and the solutions they created, it becomes much easier to understand why today's tools exist and why the web evolved the way it did.

• Why we needed Javascript
• Why we needed jQuery (You're reading this)
• Why we needed Single-Page Applications (SPAs)
• Why we needed React
• Why we needed Node.js

HTML could display documents, but it couldn't react to users.

The web before Javascript#

When the World Wide Web first became popular in the early 1990s, websites looked very different from what we use today. They were mostly collections of linked documents. You could open a page, read its content, click a link, and move to another page. For sharing information, this worked remarkably well.

At the time, HTML was exactly what it was designed to be: a markup language for describing documents. It could define headings, paragraphs, images, tables, and links, allowing browsers to display content consistently across different computers.

The lack of interactivity wasn't considered a limitation because the web wasn't originally designed to run applications.

The Web was designed to publish and browse documents

As more people started using the internet, however, developers began imagining websites that could do much more than display information. That change exposed a limitation that HTML alone could not solve.

The problem: static pages#

As websites became more interactive, developers wanted to do more than simply display static information. They wanted pages that could respond immediately to user actions, validate forms, and react without constantly loading a new page.

HTML wasn't designed for any of that. Once a page had loaded, its content couldn't change unless the browser requested a new page from the server.

Imagine filling out a registration form:

1. You enter your details.
2. You click Submit.
3. The browser sends your data to the server.
4. The server processes the request.
5. The browser loads an entirely new page.
6. Only then do you discover you forgot to enter your email address.

Just to tell you that one field was missing, the browser had to reload the entire page. There was no way to validate your input instantly while you were typing.

Adding an item to a shopping cart, changing a quantity, logging in, and many other common tasks all meant sending another request to the server and replacing the current page. Unlike today, back then only a full page reload could update what the user saw.

As a result, every interaction interrupted what you were doing.

Developers started to realize they needed a way for websites to react immediately to user actions instead of replacing the entire page every time something changed.

That need eventually led to the creation of Javascript.

The first solution: CGI and server-side scripts#

Before we look at how Javascript solved this problem in the browser, it's worth understanding how developers first made websites dynamic on the server.

Early websites were often just collections of HTML files stored on the server.

When someone visited the home page, the server returned index.html. When they visited the contact page, it returned contact.html. Each URL simply pointed to a different file.

/          → index.html
/contact   → contact.html
/about     → about.html

That worked well for static websites, but it quickly became impractical. Imagine a website with a search box. It couldn't possibly have a separate HTML file for every search someone might type. The same problem applied to logged-in users and form submissions. The server needed a way to create the page only after it knew what the user had searched for or submitted.

Instead of returning a pre-existing file, the server began running programs that generated the HTML for each request. This allowed websites to produce different pages depending on who the user was and what they were trying to do.

CGI - Common Gateway Interface#

One of the earliest ways to do this was through CGI (Common Gateway Interface).

The name sounds more complicated than it really is.

• Common because it was a standard that any web server and any program could follow.
• Gateway because it acted as a bridge between the web server and external programs.
• Interface because it defined how the server and those programs communicated.

In simple terms, CGI gave web servers a standard way to run a program that generated a web page instead of simply returning a static HTML file.

This was a major step forward.

Later, server-side technologies such as PHP, ASP, JSP, and others made this approach much easier to build. The idea, however, remained the same: every interaction happened on the server.

If a user clicked a button, submitted a form, or searched for something, the browser still had to send a request to the server. The server generated a new HTML page, and the browser replaced the current one with the response.

The web had become dynamic, but it still wasn't interactive.

Note: If you've worked with frameworks like Next.js, you've already used this concept. Modern Server-Side Rendering (SSR) follows the same fundamental idea: the server executes code, generates HTML, and sends it to the browser. Technologies such as CGI, PHP, and ASP were earlier ways of achieving the same goal.

Why that wasn't enough#

Generating pages on the server solved many problems, but one limitation remained: the browser still couldn't execute its own logic.

Even simple tasks required talking to the server first. A website couldn't instantly check whether a required field was empty, calculate a total as you typed, or show and hide parts of the page without requesting another page from the server.

As websites grew more sophisticated, this model started to feel restrictive. Developers wanted pages that could react immediately to user input instead of waiting for a round trip to the server every time something happened.

The server was excellent at processing data and storing information, but not every interaction needed its help.

For example, if a required field was left empty or an email address was clearly invalid, the browser didn't need to ask the server to figure that out. It could check those things immediately.

Some logic belonged much closer to the user.

That raised an important question:

What if the browser could run code too?

Netscape's idea: a language for the browser#

In the mid-1990s, the web was growing at an incredible pace. One of the companies leading that growth was Netscape, whose browser had quickly become one of the most popular ways to access the web.

Netscape saw where the web was heading. Websites were no longer just collections of documents; they were slowly becoming applications. To support that future, browsers needed more than HTML. They needed a way to react to user input without constantly relying on the server.

The idea was surprisingly simple: instead of sending every interaction across the internet, let the browser execute small pieces of code directly on the user's computer.

That code could respond to clicks, validate forms before they were submitted, update parts of a page, and create a smoother, more responsive experience.

It wouldn't replace server-side programming. Instead, it would complement it by handling interactions that didn't require a trip to the server.

Javascript is born#

To make that vision possible, Netscape asked engineer Brendan Eich to create a scripting language that could run directly inside the browser. In 1995, he developed the first version of what would eventually become Javascript.

The language was originally called LiveScript, but Netscape renamed it Javascript shortly before its release. The new name reflected the popularity of Java at the time, even though the two languages were designed for different purposes.

Ironically, that naming decision still causes confusion today. Many people learning programming for the first time assume Java and Javascript are closely related, when in reality they are completely different languages that happen to share part of their name.

Unlike languages designed to build desktop applications or server software, this new language focused on making web pages interactive. It could respond to events, modify the HTML displayed in the browser, and react instantly to user actions.

For the first time, web pages were no longer limited to displaying information. They could react while the user was still on the page.

This approach completely changed the direction of the web. What started as a language for adding small interactive features would eventually become one of the most important programming languages in the world.

What Javascript could do that HTML couldn't#

Javascript gave browsers something they had never had before: the ability to run code after a page had loaded.

Instead of asking the server to handle every interaction, the browser could now respond immediately to what the user was doing. This made websites feel faster, smoother, and far more interactive.

Some of the things Javascript made possible included:

• Validating forms before they were submitted.
• Responding to button clicks instantly.
• Showing or hiding parts of a page.
• Updating content without rebuilding the entire page.
• Creating animations and visual effects.
• Reacting to keyboard and mouse events.

This didn't eliminate the need for servers. Browsers still relied on them to store data, authenticate users, and generate content. Instead, Javascript allowed the browser and the server to share the work, with each handling the tasks it was best suited for.

Although these features may seem ordinary today, in the mid-1990s they completely changed what developers expected from the web.

The browser wars#

The first versions of Javascript were intentionally small. The goal wasn't to build large applications, it was to add simple interactions to web pages.

As developers discovered new ways to use the language, websites became increasingly dynamic. At the same time, browsers competed aggressively by introducing their own features and behaviors.

Unfortunately, those features weren't always compatible.

Netscape Navigator and Internet Explorer often implemented the same ideas differently. Developers frequently had to write browser-specific code, turning cross-browser compatibility into one of the biggest challenges of early web development.

Code that worked perfectly in one browser could fail completely in another. Developers often had to write separate code paths, detect the user's browser, or accept that some features simply wouldn't work everywhere.

The language itself also evolved quickly. Some design decisions made sense for small scripts but became awkward as applications grew larger. Those early compromises are still visible in parts of the language today.

Despite these challenges, developers continued pushing the browser further than anyone had originally imagined.

AJAX changes everything#

By the early 2000s, websites were becoming increasingly interactive. Javascript was handling more work inside the browser, but developers kept running into the same limitation.

Whenever fresh data was needed, the browser still had to navigate to a new page. Updating a shopping cart, checking for new messages, or refreshing a list of products usually meant replacing the current page with a new one. That experience started to feel increasingly outdated. Developers wanted browsers to fetch new information without forcing users to leave the page they were already using.

That idea eventually became known as AJAX, short for Asynchronous Javascript and XML.

Why XML? When AJAX became popular, websites commonly exchanged data using XML, which is where the acronym comes from.

AJAX allowed browsers to communicate with the server in the background while keeping the current page exactly as it was. Instead of replacing the entire page, websites could request only the data they needed and update a small part of the interface.

This made entirely new experiences possible.

Instead of waiting for a full page reload after every action, websites could:

• Load new messages automatically.
• Update shopping carts instantly.
• Search while the user was typing.

Although modern applications rarely exchange XML anymore, the underlying idea remains the same. Today's fetch() API follows the same principle: communicating with the server without replacing the current page.

AJAX marked another major step in the evolution of the web. By allowing Javascript to communicate with the server in the background, websites became faster, smoother, and far more interactive.

How Javascript evolved after AJAX#

The arrival of AJAX marked another turning point.

Developers had proven that browsers could do far more than simply display documents. Over the years that followed, Javascript evolved from a small scripting language into the foundation of modern web applications.

Libraries such as jQuery simplified browser compatibility. Later, frameworks like Angular, React, and Vue made it possible to build complex applications that ran almost entirely inside the browser.

The language itself continued to evolve. New versions introduced features such as classes, modules, promises, arrow functions, and async/await, making Javascript easier to write and maintain.

Eventually, Javascript expanded beyond the browser.

With the introduction of Node.js, developers could use the same language on both the client and the server. Instead of switching between multiple programming languages, teams could build entire applications using Javascript across the full stack.

What started as a lightweight scripting language had become one of the foundations of modern software development.

The trade-offs we still live with#

Javascript solved one of the biggest limitations of the early web, but every solution comes with trade offs.

As browsers became more capable, Javascript grew from a small scripting language into one of the world's most widely used programming languages. Along the way, the web became far more powerful but also far more complex.

Modern applications often depend on frameworks, build tools, package managers, and thousands of lines of Javascript before they become fully interactive. At the same time, the language has remained remarkably backward compatible. Features introduced decades ago still exist because removing them would break countless websites.

Those trade-offs have allowed the web to evolve without leaving older websites behind. While Javascript isn't perfect, it's difficult to imagine today's web without it.

Key takeaways#

• The early web was designed to publish and browse documents, not run applications. HTML could describe content, but it couldn't respond to user actions after a page had loaded.
• Javascript brought programming directly into the browser, making websites interactive.
• AJAX allowed browsers to communicate with servers without replacing the entire page.
• Over time, Javascript evolved from a simple scripting language into a platform used across browsers, servers, desktop applications, and more.

Frequently asked questions#

Why wasn't HTML enough?#

HTML was designed to describe and structure documents. It could display text, images, links, and forms, but it couldn't execute logic or respond to user actions after a page had loaded. Javascript filled that gap by allowing browsers to run code.

Could websites work without Javascript today?#

Yes. A website can still function without Javascript, especially if it mainly displays content. However, many modern features such as instant form validation, interactive maps, live search, drag-and-drop interfaces, and single page applications (SPA) depend on Javascript.

Is Javascript the same as Java?#

No. Despite their similar names, Javascript and Java are different programming languages with different designs and use cases. Netscape chose the name "Javascript" largely for marketing reasons because Java was extremely popular at the time.

Why does Javascript have so many strange behaviors?#

Many of Javascript's unusual behaviors are the result of design decisions made in its early years. Rather than breaking millions of existing websites, the language has remained highly backward compatible, preserving behaviors that developers still encounter today.

What would the web look like if Javascript had never existed?#

Without Javascript, websites would likely behave much like they did in the early days of the web. Most interactions would require the browser to request a new page from the server, and many of the responsive experiences we take for granted today wouldn't exist. While another browser language might eventually have emerged, the modern web would almost certainly have evolved very differently.

Explore the series#

I wasn't building websites when the web was just HTML or when Javascript didn't exist. Like many developers, I learned modern frameworks first and only later became curious about how we got here.

This series is my way of connecting those dots. By looking back at the problems developers faced and the solutions they created, it becomes much easier to understand why today's tools exist and why the web evolved the way it did.

• Why we needed Javascript (You're reading this)
• Why we needed jQuery
• Why we needed Single-Page Applications (SPAs)
• Why we needed React
• Why we needed Node.js

https://themissinglevel.dev

A few moments later, the website appears.

It feels almost instant, but your browser couldn't possibly know where to find the website on its own. The internet doesn't route traffic using names like themissinglevel.dev. It routes traffic using IP addresses such as 203.0.113.42 or IPv6 addresses like 2001:db8::42.

Without first finding that IP address through a DNS lookup, your browser wouldn't know where to send the request.

So before anything else can happen, your browser has to answer a simple question:

Which computer should I connect to?

Think of it like calling someone on your phone. You tap a contact named Joe instead of memorizing a phone number. Before the call can be placed, your phone looks up the number associated with that contact.

Your browser works in much the same way. Before it can connect to a website, it performs a DNS lookup to find the IP address associated with the domain.

      You type a domain

      themissinglevel.dev
              ↓
      DNS finds the IP
              ↓
         203.0.113.42
              ↓
Browser sends the request to that IP

Without DNS, the browser wouldn't know where to connect, so the request could never reach the website.

Now let's see what actually happens when your browser looks up a domain name.

What exactly is DNS?#

Although DNS (Domain Name System) often feels like a single service, it isn't. It's a distributed system made up of thousands of DNS servers around the world. Each DNS server is responsible for only a small part of the internet's namespace, and together they can resolve millions of domain names.

This distributed design makes DNS scalable, resilient, and fast. If every domain on the internet had to be stored in one central database, the system would quickly become impossible to manage. Instead, responsibility is shared across many DNS servers. Each one manages a different part of the DNS hierarchy and works together with the others to answer queries.

Because each server only manages a small part of the internet's namespace, DNS can continue to grow without relying on one massive central database.

How a DNS lookup works, step by step#

Although a DNS lookup can involve several servers across the internet, the browser always starts with the fastest option: checking whether it already knows the answer.

Step 1: The browser checks its DNS cache#

The browser's first question isn't "Which DNS server should I contact?"

It's:

"Have I looked up this domain recently?"

Modern web browsers maintain a small DNS cache in memory to speed up future DNS lookups. If you've recently visited the same website, the browser may already have the corresponding IP address stored locally.

For example, if you visited themissinglevel.dev a few minutes ago, the browser might already know that it resolves to 203.0.113.42.

In that case, there's no need to perform another DNS lookup. The browser can immediately begin establishing a connection with the server, making the page load a little faster and avoiding unnecessary network traffic.

            User enters
       themissinglevel.dev
                ↓
      ┌─────────────────────┐
      │ Browser DNS Cache   │
      └─────────────────────┘
           │           │
          Hit         Miss
           │           │
           ↓           ↓
          Use       Check OS
       cached IP   DNS Cache  

Cache hit: The requested data is found in the cache.

Cache miss: The requested data isn't in the cache, so the system has to look elsewhere.

If the browser doesn't have a cached entry, or if the cached entry has expired, it asks the operating system to continue the search.

Step 2: The operating system checks its DNS cache#

Like the browser, modern operating systems maintain their own DNS cache. Unlike the browser's cache, however, the operating system's cache is shared across applications. This means that if another browser or application (e.g. curl) recently looked up the same domain, the IP address may already be stored in the operating system's cache.

If a valid cached entry exists, the operating system returns the IP address to the browser, which can immediately begin establishing a connection.

If not, the operating system forwards the DNS query to its configured recursive DNS resolver.

Step 3: The request reaches a recursive DNS resolver#

The operating system sends the DNS query to a recursive DNS resolver. This is a remote server operated by your internet service provider (ISP), your organization, or a public DNS provider.

It's called recursive because it takes responsibility for finding the complete answer on your behalf. Instead of simply pointing to another DNS server, it continues querying other DNS servers until it either finds the IP address or determines that the domain doesn't exist.

            Your Computer
                  │
                  │ DNS query
                  ↓
  ┌─────────────────────────────┐
  │    Recursive DNS Resolver   │
  └─────────────────────────────┘
                  │
       "I'll continue searching
        until I find the answer."
                  │
                  ↓
          Other DNS servers...
                  │
                  ↓
           Final IP address
                  │
                  ↓
            Your Computer

Before contacting other DNS servers, the resolver first checks its own cache. If another user recently requested the same domain and the cached record is still valid, it can immediately return the IP address to your computer.

If the answer isn't cached, the resolver begins following the DNS hierarchy. Rather than contacting DNS servers at random, it queries them in a specific order:

1. Ask a root nameserver which top-level domain (TLD) nameserver to contact.
2. Ask the TLD nameserver which authoritative nameserver to contact.
3. Ask the authoritative nameserver for the domain's IP address.

Don't worry if some of these terms are unfamiliar. We'll explain what each server does and walk through every step in the following sections.

Step 4: The resolver asks a root nameserver#

If the recursive DNS resolver can't find the answer in its cache, it begins searching the DNS hierarchy.

The first stop is a root nameserver. A root nameserver is a special DNS server at the very top of the DNS hierarchy. Rather than storing the IP addresses of individual websites, it acts like a directory, knowing which nameservers are responsible for each top-level domain (TLD), such as .com, .dev, .org, and .net.

               Root Nameserver
            "Who manages each TLD?"
   ┌─────────────────┼─────────────────┐
   ↓                 ↓                 ↓
┌─────────┐     ┌─────────┐      ┌─────────┐
│  .com   │     │  .org   │      │  .dev   │
│   TLD   │     │   TLD   │      │   TLD   │
│ Server  │     │ Server  │      │ Server  │
└─────────┘     └─────────┘      └─────────┘

So the resolver asks:

"Where can I find information about themissinglevel.dev?"

The root nameserver doesn't return an IP address. Instead, it replies with the addresses of the nameservers responsible for the .dev top-level domain.

Resolver                Root Nameserver
   │                           │
   │ Where can I find          │
   │ themissinglevel.dev?      │
   │──────────────────────────>│
   │                           │
   │ "I don't know, but ask    │
   │ one of the .dev           │
   │ nameservers."             │
   │<──────────────────────────│

Step 5: The resolver asks a TLD nameserver#

Using the information returned by the root nameserver, the resolver contacts one of the .dev TLD nameservers.

A top-level domain (TLD) nameserver knows which authoritative nameserver is responsible for every domain registered under its TLD. It doesn't know the domain's IP address, but it knows where to find the server that does.

The resolver asks:

"Who is responsible for themissinglevel.dev?"

The TLD nameserver replies with the address of the domain's authoritative nameserver.

Resolver              .dev TLD Nameserver
   │                           │
   │ Where can I find          │
   │ themissinglevel.dev?      │
   │──────────────────────────>│
   │                           │
   │ "Ask this authoritative   │
   │ nameserver."              │
   │ Authoritative Nameserver  │
   │<──────────────────────────│

Step 6: The resolver asks the authoritative nameserver#

Using the information returned by the TLD nameserver, the resolver contacts the authoritative nameserver for themissinglevel.dev.

An authoritative nameserver stores the official DNS records for a domain and provides the authoritative answer during a DNS lookup. Unlike the root and TLD nameservers, it has the final answer.

The resolver asks:

"What is the IP address of themissinglevel.dev?"

The authoritative nameserver looks up the requested DNS record and replies:

themissinglevel.dev → 203.0.113.42

The resolver now has the answer it was looking for. Before returning it to your computer, it usually stores the result in its cache for a period of time so future requests for the same domain can be answered much faster.

Finally, the resolver returns the IP address to your operating system, which then passes it to the browser.

           Resolver
               │
 "What's the IP address of
  themissinglevel.dev?"
               │
               ↓
 ┌──────────────────────────┐
 │ Authoritative Nameserver │
 └──────────────────────────┘
               │
               │ 203.0.113.42
               ↓
            Resolver

Step 7: The browser can finally connect to the server#

At this point, DNS has finished its job.

The browser now knows the website's IP address, so it can begin establishing a connection.

This typically involves:

1. Opening a TCP connection.
2. Performing a TLS handshake if the site uses HTTPS.
3. Sending the first HTTP request.

That first HTTP request also includes request headers, which tell the server things like which content types the browser accepts, whether it already has cached resources, and much more. If you're curious about what those headers do and which ones you'll encounter most often, check out 7 HTTP request headers every developer should understand.

Once the server receives the request, it can start sending back the HTML, images, CSS, Javascript, and everything else needed to display the page.

DNS doesn't download websites. It simply tells your browser where to find them.

If you'd like to follow what happens next, from the TCP connection and TLS handshake all the way to HTML parsing and rendering the first pixel on screen, continue with What happens after you press Enter.

What happens if DNS can't find the domain?#

Sometimes a DNS lookup fails because the requested domain or DNS record can't be found.

If the authoritative nameserver doesn't contain the requested domain or record, it returns a response indicating that the domain doesn't exist (commonly called NXDOMAIN, short for Non-Existent Domain).

When that happens, the resolver has nowhere else to look, so it returns the failure to your computer.

Your browser then displays an error such as:

• "This site can't be reached"
• "Server not found"
• "DNS_PROBE_FINISHED_NXDOMAIN"

In many cases, the problem isn't that the website is offline. The domain simply couldn't be resolved to an IP address.

A real DNS lookup example#

You can perform your own DNS lookup from the command line using the dig (Domain Information Groper) command. It's a command-line tool for querying DNS servers and is commonly available on Linux and macOS. Windows users can install it through tools such as BIND or use the built-in nslookup command instead.

dig themissinglevel.dev

Among the output, you'll see an ANSWER SECTION similar to this:

;; ANSWER SECTION:
themissinglevel.dev.    300    IN    A    104.21.14.102
themissinglevel.dev.    300    IN    A    172.67.158.160

Breaking this down:

• themissinglevel.dev: the domain name that was queried.

• 300: the TTL (Time To Live), measured in seconds. It tells DNS resolvers how long they can cache this answer before asking again. In this example, the result can be cached for 5 minutes.

• IN: indicates that this record belongs to the Internet. You'll see IN in almost every DNS lookup.

• A: the DNS record type. An A record maps a domain name to an IPv4 address. (For IPv6 addresses, DNS uses an AAAA record instead.)

• 104.21.14.102 and 172.67.158.160: the IPv4 addresses returned for the domain. Notice that there are two A records. This is common for websites that use multiple servers or a CDN, allowing traffic to be distributed across different IP addresses for better performance and reliability.

Common misconceptions about DNS#

DNS and HTTP are not the same thing#

DNS happens before HTTP.

DNS finds the server's IP address. HTTP is then used to request pages and other resources from that server.

DNS doesn't know what page you're visiting#

DNS only resolves the domain name.

Whether you visit:

• example.com
• example.com/about
• example.com/blog/article

the DNS lookup is exactly the same because the domain hasn't changed.

DNS isn't one giant database#

DNS is a distributed system made up of thousands of servers around the world.

Each server is responsible for only a small part of the overall hierarchy.

How do you point a domain to your server?#

Imagine you've just deployed a new website to a VPS with the IP address 203.0.113.42.

If you're setting up a brand-new domain, it's also worth checking whether it has been used before. A domain's previous history can affect SEO, email deliverability, and even browser trust. I explain why in Why you should check a domain's history before buying it.

To make mywebsite.com point to your server, you log in to your DNS provider (such as Cloudflare) and create an A record:

Type: A
Name: @
Value: 203.0.113.42

When someone later visits https://mywebsite.com, their browser performs a DNS lookup, resolves the domain name to 203.0.113.42, and then connects to your server.

Without that DNS record, browsers wouldn't know where your website is hosted.

Remember the DNS caches from earlier? Even if your new DNS record has propagated successfully, your browser, operating system, or DNS resolver may still have the previous result cached. If that happens, you might not see your website immediately. Waiting for the cache to expire, or clearing your local DNS cache, usually resolves the issue.

Frequently asked questions#

Can one domain have multiple IP addresses?#

Yes.

A domain can have multiple A records (which map a domain to IPv4 addresses) or multiple AAAA records (which map a domain to IPv6 addresses).

In many cases, each IP address belongs to a different server. When someone visits the domain, DNS can return multiple IP addresses, allowing requests to be distributed across those servers. This helps with load balancing, redundancy, and improving availability.

For example:

example.com.    A    192.0.2.10
example.com.    A    192.0.2.11

When a DNS resolver looks up example.com, it may receive both IP addresses and connect to one of them.

Is DNS secure during a DNS lookup?#

By default, DNS queries are sent without encryption, which means other systems on the network may be able to observe which domains you're looking up.

Technologies such as DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries while they're being transmitted, making them much harder to intercept.

However, encryption only protects the communication between your device and the DNS resolver. It doesn't guarantee that the DNS response itself is genuine.

That's where DNSSEC (Domain Name System Security Extensions) comes in. DNSSEC adds digital signatures to DNS records, allowing resolvers to verify that the response really came from the domain's authoritative nameserver and wasn't altered or forged along the way.

Without DNSSEC, an attacker could potentially forge a DNS response and redirect users to the wrong server.

DNS troubleshooting tips worth remembering#

Here are a few practical things worth remembering the next time you're working with domains or debugging network issues:

• Not every connection problem is a server problem. If a domain can't be resolved, the browser never reaches your server.
• DNS changes aren't always visible immediately. Before assuming propagation is still in progress, remember that your browser, operating system, or DNS resolver may have cached the previous result. You may need to wait for the cache to expire or clear your local DNS cache.
• One domain can point to multiple IP addresses. This is commonly used for load balancing, redundancy, and CDNs.
• Keep dig in your toolbox. It's one of the quickest ways to verify DNS records and troubleshoot domain-related issues.

I know I have.

In my day to day work, I deal with HTTP requests and responses all the time. I inspect response objects, check status codes and look at response bodies when something goes wrong or when I'm building something new.

Yet somehow, I never spent much time looking at the headers themselves. They were always there, but they felt like background noise rather than something worth understanding.

So what changed? Why did I decide to look at them now?

I'm not sure there was a specific reason. It just occurred to me that I'd spent years walking past this part of HTTP without ever stopping to see what was there. It's a bit like living in the same city for years and suddenly deciding to visit a museum you've walked past hundreds of times. It was always there. I just never made the time.

Then one day, it simply felt like it was time.

If HTTP requests and responses are such a fundamental part of web development, why had I never stopped to understand this piece of the conversation?

One thing I've noticed about myself is that I understand new concepts much more easily when I can actually see them. I don't know whether it's the frontend side of me talking, but I've always found it easier to learn when I have something tangible to look at: a log, a network request, a metric or some real output. It helps me visualize what's happening.

HTTP headers turned out to be perfect for that because you don't have to imagine anything about them. You can inspect HTTP headers yourself.

Open your browser's Developer Tools, switch to the Network tab and click on any request, or use a CLI tool like curl.

In this article, we'll use curl because it gives us a clear view of the HTTP conversation.

Enough talking, let's look at a real request.

We'll make a simple GET request to example.com, a domain reserved specifically for documentation and examples.

If you're curious about everything that happens before the browser sends this request, I've written about the journey from typing a URL to sending an HTTP request.

All we need is:

curl -v https://example.com

The -v (verbose) flag tells curl to show the full HTTP conversation, including both the request headers sent by the client and the response headers returned by the server.

The output contains much more than just the headers. It also includes information about the network connection and the TLS handshake. To keep things simple, I've included only the header portion below.

> GET / HTTP/2
> Host: example.com
> User-Agent: curl/8.7.1
> Accept: */*

< HTTP/2 200
< Content-Type: text/html
< Content-Length: 1248
< Cache-Control: max-age=3600

The > lines are the request headers sent by the client, while the < lines are the response headers returned by the server.

Even if you've never looked at request and response headers before, one thing probably stands out immediately.

Most of the names are plain English.

Host, User-Agent, Content-Type and Cache-Control are all fairly descriptive once you stop and read them. You don't need to memorize every HTTP header. After you understand a handful of the common ones, you'll start recognizing the patterns.

Every HTTP header follows the same structure. It's simply a name followed by a value, separated by a colon.

Host: example.com
Content-Type: text/html

The name tells you what information is being sent. The value contains that information.

As developers, we've all worked with key-value pairs in one form or another, whether it's Javascript objects, dictionaries or maps. HTTP headers follow exactly the same idea. They're simply a collection of key-value pairs describing the request or the response.

Now that we've seen what HTTP headers look like, let's take a step back. Before we look at what each header does, it's worth asking a more fundamental question:

Why do HTTP headers exist?#

I started wondering about headers by trying to remove them from the equation to better understand their role.

Do we actually need HTTP headers?

After all, the browser wants a page and the server sends one back. Why isn't the conversation simply a request followed by a response?

Let's ignore headers for a moment.

Imagine your browser sends a request, the server replies with a stream of bytes and that's the end of the conversation.

The browser immediately has a problem.

What are those bytes? Are they HTML, JSON or an image? Should they be displayed in the browser or downloaded as a file? Can they be cached? Did the server create a session cookie?

My first thought was that perhaps the browser could simply inspect the data and figure it out. For some file formats, that's actually possible. Images, PDFs and other file types often have distinctive signatures that make them easier to identify.

The more I thought about it, the less I liked the idea of relying on guesses. Not every format is easy to identify, different browsers could make different decisions and, as we'll see in a future article, guessing content has caused real security problems in the past. Then how was this solved?

HTTP takes a much simpler approach.

Instead of asking the browser to guess, the sender provides information about what it's sending before the actual data arrives.

That kind of information has a name: metadata.

You've probably heard the phrase "data about data" before. That's exactly what metadata is. It isn't the content itself; it's information that describes the content.

And that's exactly what HTTP request and response headers are.

They don't contain the page itself. They contain metadata about the request or the response, helping the other side understand what it's about to receive and how it should handle it.

Think of headers as instructions that travel alongside the request or response rather than the content itself.

What is the difference between request and response headers?#

One thing that surprised me while learning about HTTP headers was realizing that they aren't just something the server sends back.

Every HTTP conversation contains two sets of headers. The client sends request headers before the request, and the server sends response headers before the response. Together, they describe the two halves of the HTTP conversation.

This article focuses on request headers. In the next one, we'll switch sides and explore the response headers sent back by the server. Stay tuned!

The 7 most common HTTP request headers#

Every HTTP request includes a collection of HTTP request headers. Some identify the client, others describe what it expects from the server, and some carry information that allows the server to recognize or authorize the request.

The first few headers tell the server who is making the request and which website the request is intended for.

Host header#

The Host header tells the server which website the browser is trying to access. You'll typically see it like this:

Host: example.com

If it feels confusing don't worry. At first this confused me too.

Didn't the browser already connect to example.com? Why does it need to send the domain name again?

Here's what actually happens:

• When you type a URL such as example.com, one of the first things that happens is that DNS resolves the domain name to an IP address.
• The browser then sends the request to that IP address.
• When the request reaches the server, the server already knows which IP address the request arrived on. What it doesn't know yet is which website hosted on that server should handle it.
• That's where the Host header comes in. It tells the server exactly which website the client is trying to access.

This becomes much easier to understand when multiple websites share the same server. Imagine two different domains both point to the same IP address:

example.com -> 203.0.113.10
example.net -> 203.0.113.10

Both requests arrive at exactly the same server. Without the Host header, the server wouldn't know whether you wanted example.com or example.net.

If you ever visit the IP address directly instead of the domain, you'll often see a completely different website or the server's default page. That's because the server uses the Host header to decide which website should handle the request.

User-Agent header#

This one is a little easier to understand.

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Chrome/138.0

The User-Agent header answers a simple question:

What software is making this request?

Notice that it doesn't identify you. It doesn't contain your username or prove your identity. Instead, it describes the client sending the request. For example, it could tell the server that the request came from:

• Google Chrome
• Mozilla Firefox
• a search engine crawler such as Googlebot
• a CLI tool like curl

So why is this useful?

Historically, websites often returned slightly different content depending on the browser because browsers supported different features. Today, a much more common use is analytics, allowing website owners to see which browsers and devices are visiting their site. Search engine crawlers also identify themselves using the User-Agent header, making it easy for servers to recognize that the request is coming from a crawler.

One important thing to remember is that the User-Agent header should never be trusted for authentication or authorization. It's just information provided by the client, and the client can change it to anything. That applies to every header on this page, and it's a specific case of the broader rule that a server can never trust your browser.

For example, this command makes curl identify itself as Googlebot:

curl -v -A "Googlebot" https://example.com

The server receives:

User-Agent: Googlebot

even though the request was sent by curl.

In other words, the User-Agent is useful as a hint, but it should never be treated as proof of identity.

User-Agent ≠ Authentication

After introducing itself, the browser also explains what it's expecting in return. These headers describe the formats, languages and compression methods the client is willing to accept.

Accept header#

The Accept header tells the server what kind of response the client is willing to receive.

For example:

Accept: text/html

In this case, the client is saying that it's expecting an HTML document. Other common values include:

Accept: application/json
Accept: image/webp
Accept: */*

The client is expressing a preference, not giving the server an order. The server decides whether it can satisfy that preference. If it can't, it may respond with 406 Not Acceptable, although in practice many servers simply ignore the header and return their default format.

You'll also come across other Accept-* headers that follow the same idea.

For example, Accept-Language tells the server which languages the client prefers:

Accept-Language: fr,en;q=0.8

The q value indicates preference. In this example, the client prefers French but is also willing to accept English if French isn't available.

Accept-Encoding header#

Another common one is Accept-Encoding, which tells the server which compression formats the client understands.

Accept-Encoding: gzip, br

In other words, the browser is saying:

"If you want to compress the response before sending it, I know how to decompress gzip and Brotli (br)."

If the server decides to compress the response, it lets the browser know by including a Content-Encoding response header. The browser then automatically decompresses the response before displaying the page. The entire process is completely invisible to the user.

💡 Did you know?
Many HTML, CSS and Javascript files become 70–90% smaller when compressed with modern algorithms like Gzip or Brotli. That's one of the reasons websites can load much faster, even though the browser still receives exactly the same content after decompressing it.

Origin header#

One more request header worth knowing is Origin.

Origin: https://example.com

Unlike the headers we've looked at so far, the Origin header tells the server which website initiated the request. You'll most often encounter it when building or consuming APIs that are called directly from a browser.

For example, imagine your frontend is running at https://app.example.com and it sends a request to an API at https://api.example.com. The browser automatically includes the Origin header, allowing the server to decide whether the cross-origin request should be allowed.

So far, we've looked at request headers that identify the client and describe the kind of response it can handle. Some request headers serve a different purpose: they help the server recognize the client or verify that it has permission to access a protected resource.

Unlike the Referer header, which can include the full URL of the previous page, the Origin header contains only the origin (scheme, host and port). That's one of the reasons browsers use it when enforcing CORS policies.

Cookie header#

The Cookie header is how the browser sends information it has previously stored back to the server. Most commonly, this includes a session identifier that allows the server to recognize a returning user.

Imagine you log in to a website. The server doesn't remember you simply because you're using the same browser. Instead, it asks the browser to store a small piece of information called a cookie. On every future request, the browser automatically sends that cookie back using the Cookie header. This is one of the most common ways websites keep you logged in as you move from page to page.

Authorization header#

Unlike Cookie, the Authorization header is used when the client wants to explicitly prove it has permission to access a protected resource. Instead of relying on information stored by the browser, the client includes credentials such as an API key or an access token directly in the request.

You'll encounter this header frequently when working with APIs. If you're wondering how a website can verify your identity without ever storing your password, I wrote about how password hashing works and why websites can't tell you your password.

For example, after logging into an application, the client might receive an access token and include it in every subsequent request. The server validates that token before deciding whether to return the requested resource or reject the request.

Although both headers are commonly involved in authentication, they serve different purposes. Cookies are usually managed automatically by the browser, while the Authorization header is typically added explicitly by the client or application.

What to remember about HTTP request headers#

• Every HTTP request includes one or more HTTP request headers. Some identify the client, others describe the response it can handle, and some carry authentication or session information.
• Request headers are metadata sent before the request body.
• The Host header tells the server which website should handle the request.
• The User-Agent header identifies the software making the request, not the user.
• The Accept family of headers tells the server what kinds of responses the client can handle.
• Cookie and Authorization are commonly used to recognize or authenticate a client, but they serve different purposes.
• Understanding request headers makes browser DevTools and network debugging much easier.

The next time you open your browser's Network tab, don't skip over the headers. They're no longer just a list of key-value pairs, they're the browser and the server explaining exactly what they're about to do.

The perfect domain for your next project is somehow still available. It's short, memorable and surprisingly inexpensive. Your cursor is already hovering over the Buy button when a simple question pops into your head.

Has anyone owned this domain before?

Most of us don't think about that. If the registrar says the domain is available, we assume it's a fresh start. That's what I used to think too.

Then, while searching for a domain for a personal project, I became curious. I wanted to know whether someone else had used it before me. I expected to find almost nothing. Instead, I discovered that domain names can carry years of history, and sometimes that history matters.

A domain isn't just a name. In many ways, it's an identity that has existed on the internet long before you arrived.

A domain has a memory#

Search engines, browsers and email providers don't really know who owns a domain. They mostly focus the domain itself.

Imagine that someone spent years running a legitimate blog on a domain. Over time, other websites linked to it, people bookmarked its pages and search engines learned to trust it.

Now imagine the opposite.

Perhaps the domain was used for spam, fake online shops or phishing pages. Maybe thousands of low-quality websites linked to it in an attempt to manipulate search rankings. Even after the owner disappears, some of that history can remain.

That doesn't mean every old domain is a bad purchase. In fact, most aren't.

It simply means that buying a domain is sometimes more like buying a second-hand car than buying a brand-new one.You don't just inherit the keys. You may also inherit part of its story.

What kind of history can you inherit?#

The most common thing is an old backlink profile.

If you're not familiar with the term, a backlink is simply a link from another website to yours. Search engines use backlinks as one of many signals to understand how websites are connected and how trustworthy they might be.

Years ago, many website owners tried to improve their rankings by creating thousands of artificial backlinks. Google has become much better at ignoring those today, but they don't disappear overnight. If a domain has a strange backlink profile, it's worth knowing before you build your next project on it.

Another possibility is old content.

Even after a website disappears, search engines and other websites may still remember it. Visitors might continue trying to access pages that no longer exist. You'll sometimes notice strange URLs appearing in your analytics, simply because someone bookmarked them years ago.

There are also more serious cases.

Domains that previously hosted malware or phishing pages may still appear in security databases. Domains used for sending spam can have a damaged email reputation.

None of these problems are impossible to fix, but they're much easier to avoid than repair.

How I investigate a domain#

Whenever I find a domain that looks promising, I spend a few minutes checking its past. I'm not interested in who owns it today. I want to know whether someone owned it before me, what they used it for and whether they left behind anything that could become my problem later.

The whole process usually takes less than ten minutes, and it may save you from buying a domain you'll later regret.

1. Check the Wayback Machine#

The first stop is always the Wayback Machine. Instead of showing what a website looks like today, it lets you browse snapshots from years ago. Sometimes I find a legitimate business that simply shut down. Sometimes it's an abandoned personal blog. Occasionally, I discover something I'd rather avoid entirely.

This single check often tells me whether the domain has a normal history or whether something feels off.

2. Check the registration status#

Next, I check the domain with RDAP (Registration Data Access Protocol). It's the modern replacement for WHOIS and provides registration information about a domain, such as when it was first registered and whether it's currently registered.

You can query RDAP directly from your terminal:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.events'

If you're not familiar with jq, it's a command-line tool for reading and filtering JSON output.

The response contains several pieces of information about the domain. One of the most useful fields is the events:

[
  {
    "eventAction": "registration",
    "eventDate": "1995-08-14T04:00:00Z"
  },
  {
    "eventAction": "expiration",
    "eventDate": "2026-08-13T04:00:00Z"
  },
  {
    "eventAction": "last changed",
    "eventDate": "2026-01-16T18:26:50Z"
  },
  {
    "eventAction": "last update of RDAP database",
    "eventDate": "2026-07-14T10:24:27Z"
  }
]

The registration event tells me how long the domain has existed. If the registration date is many years old, I know the domain has a history worth investigating. If it's very recent, it may have been registered for the first time only recently.

If the command returns an empty response, don't assume something went wrong straight away.

The first time it happened to me, I thought the request had failed. It hadn't.

For the RDAP service I was using, an empty response meant the domain had never been registered before. No previous owners, no abandoned projects and no hidden surprises.

That was exactly what I was hoping to see!

3. See what Google remembers#

After that, I ask Google a simple question.

site:example.com

If Google still has hundreds of pages indexed, I immediately learn what kind of website used to exist there. If nothing appears, that's usually a good sign because Google no longer has any pages associated with the domain.

If only one or two pages appear, I don't jump to conclusions. It could simply mean the website was very small, that Google has already removed most of its pages from the index, or that only a handful of pages were ever considered worth indexing. Either way, it's another useful clue when building the bigger picture.

This doesn't guarantee the domain has a clean history, but it helps me understand whether Google still associates it with its previous life.

4. Look at the backlinks#

Then I spend a minute looking at the backlink profile with a tool like Ahrefs. I'm not performing a full SEO audit or counting every referring domain. I'm simply checking whether the links look natural or whether the domain has thousands of suspicious backlinks pointing to it.

If something looks unusual, I'll investigate further. If everything looks normal, I move on.

A worked example: checking a domain before buying it#

Let's imagine you've found themissinglevel.dev.

The name is available, it's memorable and the price looks good. Before clicking Buy, you decide to spend a few minutes checking its history.

The first stop is the Wayback Machine. You discover that the domain previously belonged to a small indie game development blog. The snapshots are consistent over several years, the content looks legitimate and nothing immediately raises any concerns.

Next, you check the registration details with RDAP. The registration event shows that the domain was first registered in 2019, so you know it has some history behind it rather than being a brand-new registration.

After that, you ask Google a simple question.

site:themissinglevel.dev

No pages appear in the results. That's usually a good sign because Google no longer has any content associated with the domain.

Finally, you take a quick look at the backlink profile using Ahrefs. There are a few dozen backlinks from game development blogs, GitHub repositories and developer forums. Everything looks natural rather than manipulated.

At this point, you still don't know everything about the domain, but you've removed most of the uncertainty. In less than ten minutes, you've built enough confidence to feel comfortable moving forward with the purchase.

Now imagine the opposite.

The Wayback Machine shows that the domain previously hosted online casinos. Google still has dozens of gambling-related pages indexed, and the backlink profile is filled with thousands of links from unrelated, low-quality websites.

Could you still buy the domain?

Of course.

Would I?

Probably not.

None of those signals automatically mean the domain is unusable. However, they don't align with the clean starting point I'm looking for. If I can choose between a domain with years of questionable history and one with little or no baggage, I'll choose the cleaner option every time.

History isn't always bad#

It's easy to think every old domain is something to avoid.

That's not true.

Some expired domains belonged to respected businesses, universities or popular blogs. They earned genuine trust over many years, which is exactly why some of them sell for hundreds or even thousands of dollars.

The lesson isn't to avoid old domains.

The lesson is to understand them before you spend your money.

Key takeaways#

If you only remember three things from this article, let them be these:

• An available domain isn't necessarily a brand-new domain. A few minutes of research can save you from inheriting somebody else's problems.
• Start with the Wayback Machine. It's the quickest way to understand what a domain was used for in the past.
• Use RDAP and a quick Google site:<your next domain> search to see how long the domain has existed and what Google still remembers about it.

My first reaction was disbelief. If the server doesn't know my password, then how does it know whether I typed the correct one when I log in tomorrow? It felt like one of those statements developers repeat because it sounds clever, but the more I thought about it, the less sense it made.

As it turns out, it wasn't a trick at all. The explanation is surprisingly elegant, and once you understand it, you begin to appreciate how much thought has gone into protecting something as simple as a login form.

The interesting part is that this isn't some cutting-edge security feature used only by banks or large technology companies. It's a principle that every modern web application should follow, whether it's a small personal project or a platform serving millions of users.

The obvious solution would actually be the worst one#

Imagine you're building your first website.

Users need accounts, so you create a users table in your database with an email address and a password column. Whenever someone signs up, you simply store whatever they typed. The next time they log in, you compare the password they entered with the one stored in the database.

From a programming perspective, it sounds perfectly reasonable. From a security perspective, it's a disaster waiting to happen.

If someone gains access to your database, they immediately gain access to everyone's passwords. Even worse, many people reuse the same password across multiple websites. A single breach could allow attackers to access email accounts, social media profiles, online stores, and countless other services.

That's why storing plain text passwords is considered one of the biggest mistakes a developer can make.

What does the server store instead?#

Instead of storing the password itself, the server stores the result of a hash function.

You can think of a password hash as a digital fingerprint. Every time you provide the same input, you get exactly the same output. Unlike encryption, hashing is a one-way operation. It's designed to be easy to compute, but practically impossible to reverse. For example, imagine a user chooses the password:

myPassword123

After being processed by a hashing algorithm, it could become something like:

a336f671080fb420c27461fcf4f2c8d1d87b8a5f6d6f8b5f8f13c2b7d5ad7168

That's what gets stored in the database. Even changing a single character in the password produces a completely different hash.

How a password becomes a password hash

User creates a password
        ↓
Server receives the password
        ↓
Password is passed to the hashing algorithm
        ↓
A password hash is generated
        ↓
Only the password hash is stored in the database

If you look at that string, there's nothing that hints at the original password. It's just a long sequence of characters that appears completely random.

Modern applications typically use password hashing algorithms such as bcrypt or Argon2, which are specifically designed to make password cracking as difficult as possible. The important idea, though, is much simpler than the algorithms themselves. The server stores the transformed value, not the password you originally typed. It's also worth noting that the hashing happens on the server rather than in the browser, for the same reason a server can never trust your browser to have done the work honestly.

But how can the website verify my password?#

This was the part that confused me the most.

If the original password is gone, how can the server possibly know whether I typed it correctly the next day?

The trick is that it never tries to recover the original password.

Instead, when you log in, the server takes the password you just entered and runs it through the exact same hashing algorithm. If the newly generated password hash matches the one already stored in the database, then the passwords must have been identical.

How the server verifies your password

User enters their password
        ↓
Server receives the password
        ↓
Password is passed to the hashing algorithm
        ↓
A new password hash is generated
        ↓
Compare with the stored password hash
        ↓
Match?
├── Yes → User is authenticated
└── No  → Access denied

The server never compares passwords directly. Instead, it hashes the password you just entered and compares the resulting hash with the one stored in the database.

That's a subtle difference, but it's one of the reasons modern authentication is so secure.

Why can I reset my password?#

At this point another question naturally appears.

If websites don't know my password anymore, why can I click Forgot Password and get back into my account?

Many people assume the website simply emails them the password it has stored.

A properly designed website can't do that, because it doesn't have the password anymore.

Instead, it generates a temporary reset token that's valid for a limited amount of time. That token proves you requested a password reset. After you choose a new password, the old hash is discarded, a new hash is generated, and the temporary token becomes useless.

This is also why you should immediately become suspicious if a website ever emails you your existing password.

If it can send your password back to you, it probably stored it in a readable form. That's a huge warning sign.

What happens if someone steals the database?#

You might wonder whether hashing makes data breaches harmless.

Not quite.

If attackers steal a database containing password hashes, they can't immediately read everyone's passwords, but they can still try to guess them. They do this by hashing millions of common passwords and comparing the results with the stolen hashes.

This is exactly why modern password hashing algorithms are intentionally slow. While a normal user only logs in occasionally, an attacker might need to test billions of password guesses. Making every guess take significantly longer turns a practical attack into one that can become prohibitively expensive.

Hashing doesn't eliminate risk.

It dramatically raises the cost of attacking the system.

One small design decision with enormous consequences#

One of the things I enjoy most about software engineering is discovering solutions that feel almost backwards.

Our instinct is often to collect more information because we think it will make the system more capable. In reality, good engineering is often about deciding what information you should never keep in the first place.

A website doesn't need to remember your password forever. It only needs a reliable way to verify that the password you enter tomorrow is the same one you chose today. Verifying the password is only the first step, though. How the website then remembers you across every later request is a separate problem with its own trade-offs.

That single design decision protects millions of users every day without them ever noticing.

The next time you sign into a website, it's worth remembering that your password probably isn't sitting in a database somewhere waiting to be read. In a well-designed system, it disappeared the moment you created your account, leaving behind only a mathematical fingerprint that proves you know the secret without revealing the secret itself.

In my opinion, that's one of those elegant ideas that makes software engineering so fascinating. Once you understand it, you'll never look at a login form in quite the same way again.

Frequently asked questions#

Can a website see my password?#

A properly designed website never stores your original password. Instead, it stores a password hash. When you log in, it hashes the password you entered and compares the resulting hash with the one stored in the database.

Is password hashing the same as encryption?#

No. Encryption is designed to be reversible, allowing the original data to be recovered with the correct key. Password hashing is a one-way process that's designed to verify passwords without ever storing or revealing the original password.

Can password hashes be reversed?#

Not directly. Password hashes are designed to be one-way, meaning you can't simply reverse them to recover the original password. However, attackers can still try to guess passwords by hashing common passwords and comparing the results with stolen password hashes, which is why strong, unique passwords are so important.

Why can websites reset my password if they don't know it?#

A password reset doesn't recover your existing password. Instead, the website generates a temporary reset token that lets you choose a new password. Once you set a new password, the old password hash is replaced with a new one.

So here is the story, told the way I wish someone had told me. You type an address, you press Enter, and for the next few hundred milliseconds your browser works through a checklist that has not really changed in thirty years: find the server, open a connection, secure the connection, ask for the page, then turn a wall of text into pixels. Every step is a place where time can quietly disappear, and that is exactly why the steps are worth knowing.

How does the browser find the server?#

The address you typed is a name, and names mean nothing to the network. The internet moves traffic between numeric IP addresses, so before anything else, the browser has to translate example.com into something like 93.184.216.34. That translation system is DNS. The simplest way to describe it is a phone book spread across thousands of servers around the world.

A full DNS lookup happens in several steps. Your machine asks a resolver, which is usually run by your internet provider or a public service like Google or Cloudflare. If the resolver does not already know the answer, it asks other DNS servers, level by level, until it reaches the servers responsible for that domain. The good news is that answers get cached at every step, in your browser, in your operating system and in the resolver itself, and each copy expires after a set time. A popular site usually resolves instantly from a nearby cache. An unknown site might need a real trip across the world before the browser even knows where to send the request.

How does the browser open a connection?#

With an IP address in hand, the browser can finally talk to the server, but it cannot simply shout "give me the page" right away. First the two machines set up a TCP connection, and they do it with a short exchange called the three-way handshake. Your machine says "I would like to talk", the server answers "I hear you, go ahead", and your machine confirms "great, starting now". Three messages, and only then does a reliable channel exist between them.

This exchange sounds like something you could skip, but you cannot, because TCP is what makes the internet dependable. The network underneath drops packets, duplicates them and delivers them in the wrong order. TCP hides all of that by numbering every piece of data and resending whatever gets lost. The handshake is how the two sides agree on the starting numbers, so the counting works. The cost is one full round trip before any real data flows. This is why physical distance to the server still matters, even with a fast connection. It is also why CDNs place servers near users: you cannot make light travel faster, but you can make the trip shorter.

How does HTTPS secure the connection?#

For an https address there is one more negotiation before the first real byte. It is called the TLS handshake, and it has two jobs. The first job is proving that you are talking to the right server. The server presents a certificate, which is a signed statement from an organization your browser already trusts, saying that this server really does speak for that domain. Your browser checks the signatures, and this check is the machinery behind every certificate warning you have ever clicked through, hopefully after reading it.

The second job is agreeing on encryption keys. The two sides perform a key exchange, which is clever math that lets them arrive at a shared secret even while someone watches every message between them. From that point on, everything they send is encrypted. All of this costs roughly one more round trip, and then, at last, the browser can ask for what you wanted.

What happens when the browser asks for the page?#

The request itself is very simple after all that setup. The browser sends an HTTP request, which is plain text that says, more or less, "GET / and here is who is asking". The server replies with a status code, response headers and the HTML itself. After three phases of pure plumbing, this is the first moment the conversation is about actual content.

It is also the moment where the server can be slow. Everything up to now was network delay, but the gap between request and response is your application: routing, database queries, template rendering, all of it happening while the browser waits. When developers talk about server response time or "time to first byte", this pause is the thing they are measuring.

How does the browser turn HTML into pixels?#

Now the browser has HTML, and the most interesting work starts. It parses the document from top to bottom, building a tree of elements called the DOM. As it reads, it keeps finding more things it needs. A stylesheet link, an image, a script tag: each one triggers another download, and some of them change how the browser behaves.

Two of these downloads are special because they can pause everything. CSS blocks rendering, because the browser refuses to paint anything before it knows how the page should look. A flash of unstyled content would be worse than a short wait. Classic script tags are even more disruptive, because Javascript can rewrite the document while it is being parsed. So the parser must stop, fetch the script, run it, and only then continue. This is why "put CSS early, load scripts with defer" became standard performance advice long ago. Fonts have their own version of this problem, where browsers hide or swap text while the real font downloads.

Once the browser has the DOM and the styling information, it runs layout, calculating where every element sits and how big it is. Then it paints, filling in actual pixels and combining the layers into a frame. That frame, the first one with real content in it, is the moment this whole story has been building toward. From keypress to this point is often under a second, and inside that second there was a distributed name lookup, two negotiated handshakes, an application doing real work and a rendering engine laying out a document. Every link you click after that repeats most of the journey, and that repeated cost is exactly what single page applications were built to avoid.

Why is this story worth knowing?#

The practical value is that "the site is slow" stops being one big mystery and becomes five small questions. Slow for everyone or only for far-away users? Look at network round trips and CDN placement. Long wait before the first byte? That is the server's part, so go look at the backend. Page arrives fast but appears late? Now you are hunting render-blocking CSS and scripts. Each phase leaves its own kind of evidence, and the waterfall chart in DevTools will show you exactly which one is taking the time.

And the next time someone asks you the interview question, you will have something better than acronyms. You will have the story: find the server, open a connection, secure it, ask for the page, then build the page from text. Everything else in web performance is a detail on top of those five steps.