Your shopping site, your social feed, your company’s timesheet system ── the pages you use without a second thought greet you still logged in, even after you close the browser and come back the next day. And yet, the server working behind them is not actually remembering you. The reality is the opposite: servers tend to forget you ── more precisely, they reset their memory every time they answer a request. The everyday experience of “being remembered” is, when you look closely, rather strange.
So why do we stay logged in? The answer is the cookie ── the same cookie from that “Accept cookies?” banner every site asks you about. If any of the following sounds familiar, keep reading.
- You click through the “Accept cookies?” banner on reflex, every time, without knowing what it means
- You can’t explain why you stay logged in ── or, the other way around, why you suddenly get logged out
- You don’t know why opening the same site on another PC or phone shows you logged out
- Someone told you “try deleting your cookies” ── but you’re not sure what deleting them actually does
This article makes two promises. ① We’ll keep the jargon to a minimum. ② We won’t stop at how it works: we’ll get to the practical decisions ── what to click on the consent banner, and what happens if you delete your cookies.
| Question | Where it’s answered |
|---|---|
| What does “servers tend to forget you” mean? | §1 |
| What exactly is a cookie? | §2 |
| How does staying logged in actually work? | §3 |
| What is “Accept cookies?” really asking? | §4 |
| Are cookies dangerous? | §5 |
| What happens if I delete them? | FAQ Q1 |
In our series recap, What happens between typing a URL and the page appearing, we followed one access as “the round trip of a single request”. This article picks up the question that follows ── if every request and every visit is complete in itself, why does the site remember you?
1. The Server Forgets You Every Time ── HTTP Is Built Not to Remember
1-1. The round trip of a request is complete in itself, every time
When you open a web page, a request travels the world, reaches the server, and an answer comes back (for the full journey, see What happens between typing a URL and the page appearing). Here’s the part that matters: that round trip is the whole story. When you click one more link, that’s a brand-new trip ── and from the server’s point of view, a request from a complete stranger.
In metaphor: the server is a front-desk clerk whose memory wipes clean the moment each interaction ends. Visit ten times in one minute, and ten times the clerk will greet you with “Welcome! First time here?” This property is called being stateless, and it’s part of the basic design of HTTP.
It sounds like a defect, but it’s deliberate. A desk that doesn’t remember can handle anyone with the same procedure ── simple, fast, and able to serve enormous crowds from all over the world at once. Throwing away the job of “remembering” from the start is one of the reasons the web could grow this big.
1-2. Then why does the web feel like it remembers you?
But that creates a contradiction. Staying logged in, the items waiting in your cart, your dark-mode setting surviving between visits ── if the clerk meets you as a stranger every time, none of that should happen.
The memoryless front desk vs what you actually experience How the machinery works (stateless) Visit 1: You ──> Server: "Nice to meet you" Visit 2: You ──> Server: "Nice to meet you" △ Zero memory, every time Visit 3: You ──> Server: "Nice to meet you" What you actually experience Visit 1: You log in Visit 2: Still logged in △ Somehow, you're remembered Next day: Still logged in
The device that bridges this gap is the star of this article: the cookie. The one-line answer, up front ── the one doing the remembering is not the server. It’s your browser.
2. What a Cookie Really Is ── a Membership Card the Store Hands You
2-1. The store gives up on remembering, and hands the customer a card instead
Even a clerk whose memory wipes clean can tell customers apart. The trick: have the customer carry a card, and show it on every visit.
That’s exactly what a cookie is. The first time you visit a site, the server attaches a note to its response ── “please hold on to this” (Set-Cookie). Your browser tucks the card into its wallet (a storage area on your PC), and the next time it sends a request to that same site, it presents the card automatically. The clerk has zero memory, but one look at the card says “ah, the customer holding this card” ── a store issuing a membership card, and a customer showing it on every visit.
The card itself is just a short string of text on a note. It is not a program, so the card can’t run or execute anything on its own ── this will matter again in §5.
2-2. The card’s rules ── shown only to the store that issued it, automatically
Membership cards follow two basic rules.
First, a card is only ever shown to the store that issued it. The card site A gave you is attached only to requests headed for site A. Your grocery store’s loyalty card means nothing at the bookstore (── that’s the rule as far as §2 is concerned. In §4, we’ll see that the “loophole” in this rule is exactly what the consent banner is about).
Second, cards expire. There are two kinds: cards thrown away when you close the browser (session cookies), and cards that stay in the wallet until a set date (persistent cookies). The “keep me signed in” checkbox is, roughly speaking, a choice between these two.
The membership card round trip ── from issuance to automatic presentation First visit You ──"Nice to meet you"────────────> Site A You <──"Welcome! Please hold this card"── Site A △ Card issued (Set-Cookie) Every visit after You ──"Hello again" + [card] ──> Site A △ Attached automatically by the browser You <──"Welcome back"────────── Site A Visiting a different store You ──"Nice to meet you"───────────> Site B △ Site A's card is not attached
3. How Staying Logged In Works ── the Card Only Carries a Number
3-1. A numbered ticket and a ledger ── what a session ID really is
We said “one look at the card and the clerk knows” ── but the card doesn’t have your name or your password written on it. The login mechanism is one notch cleverer.
When you enter your password and log in successfully, the server writes one line in its ledger ── “Customer No. 8472 = your account, logged in.” Then it hands you a numbered ticket with just that line number on it. From then on, every time your browser presents the ticket, the server looks up No. 8472 in the ledger and knows “this is you, already logged in” ── that number is the session ID, and the ledger is the server-side session.
This design has two advantages. Your password itself is never on the ticket, so even if someone sees the ticket, the password doesn’t leak (FAQ Q5). And you don’t have to retype your password every time ── presenting the ticket continues the identity check for you. By the way, this “numbered ticket” is one kind of the mechanism called a token ── our guide Password vs UUID vs Hash vs Token sorts out how it differs from passwords and hashes.
- 1Log inPassword verified. The server writes one line in its ledger.
- 2Ticket issuedA ticket carrying only the line number (the session ID) is handed over as a cookie.
- 3Every visit afterThe browser presents the ticket automatically. The server checks it against the ledger: “logged in”.
- 4The endLogout (the ledger line is erased) or the ticket expires ── back to being strangers.
3-2. The mysteries solve themselves: sudden logouts, and being a stranger on another PC
Once you have the ticket and the ledger, the everyday mysteries fall apart all at once.
Getting suddenly logged out means the ticket or the ledger expired. The ticket passed its date, the server cleaned out old ledger lines, a “log out of all devices” wiped your line, or a browser cleanup threw the ticket away ── the reasons vary, but the event is the same: the ticket and the ledger no longer match.
Being logged out on another PC or phone happens because the ticket lives in that browser’s wallet. Different wallet, no ticket ── so a new device means starting from the password again. Even on the same PC, switching browsers makes you a stranger, because each browser keeps its own wallet.
The side holding the ledger ── that is, what a server actually is ── is a big enough topic for an article of its own. We plan to cover it in a future post.
4. What “Accept Cookies?” Is Really Asking ── the Ad Company’s Membership Card
4-1. If every card were site-specific, the banner would never have existed
Every card so far has been “for that site only”. Site A’s card is shown only to site A ── cookies used within this boundary are called first-party cookies (the site’s own cards), and they’re what powers logins, carts, and remembered settings. Honestly, if these were all the world had, the consent banner would never have been born.
4-2. Showing the same card across sites ── third-party cookies and tracking
The problem is that a page isn’t built from “that site” alone. Many pages embed parts from other companies (usually ad companies) ── ad slots, analytics snippets. When you open the page, your browser sends requests to the ad company’s server too, to fetch those parts ── and per the rule from §2, the card issued by the ad company gets attached to requests headed for the ad company.
Here’s the trap. What if the news site, the recipe site, and the shopping site all embed parts from the same ad company? Then whichever site you open, you’re showing the same single “ad company membership card” everywhere you go. The ad company’s ledger accumulates a trail: “Person No. 551: news → recipes → the shoe page at the shop” ── that’s the real mechanism behind “the product I looked at yesterday is following me around on other sites”, and cards that cross sites like this are third-party cookies.
First-party vs third-party ── who gets shown which card First-party (the site's own card) News site ──> [news card] △ Stays within that site Shop site ──> [shop card] Third-party (the ad company's card) News site ┐ Recipe site ├── on every page ──> [the same ad company card] Shop site ┘ △ The trail connects across sites
This is mainly what the “Accept cookies?” banner is asking about. The site’s own cards (the ones logins and settings need) are usually treated as “strictly necessary”, and what you’re actually being asked to choose is whether to accept the advertising and analytics cards. That’s why clicking “Reject” still leaves the site’s main features working fine (FAQ Q3).
For what it’s worth, the winds have turned against this tracking mechanism: browser makers are phasing third-party cookies out, step by step. Think of it as a return to the card’s original rule ── shown only to the site that issued it ── and you know enough.
5. Are Cookies Dangerous? ── the Card Itself Is Harmless; What Matters Is How It’s Handled
5-1. Drawing the line ── the harmless side and the side that needs care
The image of “cookies = something dangerous” is half misunderstanding and half true. As in our HTTPS article, let’s draw the line with a table.
| Safe to relax about ✅ | Needs care ❌ | |
|---|---|---|
| What the card is | A short note of text. Not a program ── it can’t execute anything, virus-style | ── |
| Who sees it | Shown only to the site that issued it (first-party) | ── |
| Snooping en route | The card travels inside the secret box (HTTPS) and can’t be read along the way | ── |
| Ticket theft | ── | If someone else uses your numbered ticket, they’re logged in as you, no password needed ── the real risk of forgetting to log out on a shared PC |
| Behavior trails | ── | The ad company’s cards (third-party) become a record of your trail across sites (§4) |
| Deleting them | ── | Throw away all the cards, and every site treats you as a stranger again (FAQ Q1) |
5-2. The practical takeaways
Translating the table into everyday behavior gives us three rules.
First ── on shared or borrowed devices, always log out when you’re done. Logging out erases the ledger line, so even a leftover ticket becomes useless. Just closing the browser can leave the ticket sitting in the wallet.
Second ── on consent banners, “necessary only” or “Reject” is perfectly fine when offered. The site’s own cards remain, so logging in and shopping keep working as usual.
Third ── there’s no need to fear cookies themselves. The card is a note, not a program, and the secret box protects it in transit. The two things worth your attention: don’t let other people physically handle your tickets, and decide whose ledgers get to record your trail.
Summary ── the Essence in 4 Lines
- The server forgets, every time: HTTP is stateless ── the clerk’s memory wipes after each interaction. Not remembering is what makes it fast and massively scalable
- A cookie is a membership card: the browser does the remembering ── it stores the card a site issued and presents it automatically, to that site only
- Login is a numbered ticket plus a ledger: the ticket carries only a line number (the session ID), never your password ── and “logged out” means the ticket and ledger stopped matching
- The banner’s real question is the ad company’s card: the site’s own cards are “necessary”; what you’re choosing is cross-site tracking, and rejecting it leaves the main features working
To read on through the series ── the full journey of a request is in the series recap, the box that protects the card in transit is the HTTPS article, and how the numbered ticket (token) differs from passwords and hashes is in the random strings guide.
FAQ
Q1. What happens if I delete all my cookies?
A. Every site goes back to treating you as a stranger ── concretely, you’re logged out everywhere, your cart contents and “don’t show this again” settings disappear, and the consent banners come back. Nothing breaks: log in again and everything works as before. The reason “try deleting your cookies” is classic troubleshooting advice is that it resets any mismatch between stale tickets and the ledger.
Q2. What’s actually happening in incognito (private browsing) mode?
A. You’re browsing with a temporary visitor badge. Every membership card and numbered ticket you receive inside the incognito window expires the moment you close it ── they’re all discarded at once, which is why no history and no cards remain on your device. But while you’re wearing the badge, you look exactly the same as usual. Log in inside that window, and the badge effectively has your name on it: the site’s ledger knows it’s you, just like always. What the network sees along the way doesn’t change either. Incognito doesn’t make you anonymous ── the only thing that changes is that nothing is left behind on your device.
Q3. If I click “Reject” on the consent banner, will the site stop working?
A. In almost all cases it keeps working normally. The banner is mostly asking about advertising and analytics cards (third-party); the site’s own cards used for login and carts are usually classed as “strictly necessary” and aren’t part of the rejection (§4). You may still see ads after rejecting ── those are just ads that aren’t tailored to your trail.
Q4. What’s the difference between cookies and the cache? They always get deleted together.
A. Completely different jobs. A cookie is the membership card that says who you are; the cache is the reuse of packages (images and such) you’ve already received once. Deleting them differs too: clear cookies and you get logged out; clear the cache and pages just load slower for a while. How the cache works ── the real story behind “I updated it but nothing changed” ── is a big enough topic for its own article, planned for a future post.
Q5. Is my actual password stored inside a cookie?
A. No. As §3 showed, the ticket carries only a ledger line number (the session ID); your password is used to check your identity at the moment of login and never rides on the ticket. That said, “no password inside, therefore safe” doesn’t hold either ── if the numbered ticket itself is stolen, whoever holds it can act as you until it expires. The basics of protecting your tickets: log out on shared PCs, and don’t let other people handle your device.
Leave a Reply