Cookies vs Sessions vs Tokens: Who Remembers You're Logged In?
HTTP is stateless, so the server forgets you between requests. A cookie is just the envelope carrying the real answer — the actual axis is where the login state lives: on the server (a session) or inside the token itself (a JWT).
A cookie is just a carrier — the real question is where your logged-in state actually lives. A session keeps state on the server: the cookie holds a random id the server looks up, like a coat check, which makes revoking access easy but needs a lookup (and a shared store once you have more than one server). A token like a JWT keeps the state inside itself: the server signs it and stores nothing, just verifies the signature, like a signed wristband — it scales without a lookup, but is hard to revoke before it expires.
Transcript
HTTP has no memory. The server handles your request and instantly forgets you exist. So after you log in, how does it remember you on the very next click? Two answers — sessions and tokens — and the whole difference is one question: WHO remembers you? Let's clear up the confusion for good.
First, cookies. A cookie isn't the answer — it's just the envelope. It's a bit of data your browser stores and automatically sends back on every request. So 'cookies versus tokens' is a false fight. The cookie just carries something. The real question is what's inside — and WHERE your login state actually lives.
With a SESSION, the state lives on the server. When you log in, the server saves your data and hands you a random session ID — usually in a cookie. It's a coat check: the venue keeps your coat, you hold a numbered ticket. Every request you show the ID; the server looks it up. The SERVER remembers you.
With a TOKEN — like a JWT — the state lives in the token itself. The server signs your identity into it, and stores nothing on its own side. It's a tamper-proof signed wristband: the server just checks its own signature, no lookup needed. YOU carry the state. The server remembers nothing.
So which? Sessions are trivial to revoke — delete the record and they're logged out. But every request costs a lookup, and at scale you need a shared session store. Tokens skip the lookup entirely, so they scale beautifully across servers. The catch: with no record to delete, you can't easily revoke one before it expires.
So it was never cookies versus tokens — a cookie is just a carrier. The real axis is WHERE the state lives: on the server, or inside the pass you carry. Next time you build login, ask the one question that decides everything: who should remember you — the server, or the token in your pocket?