Cookies, sessions and why websites remember you

Updated: Oct 28, 2026

The web was designed without memory. Each request a browser sends is independent, and the server has no built-in way to know that the person asking for page two is the same one who logged in on page one. Cookies were invented to solve that, and they remain the mechanism behind staying logged in, keeping a shopping basket, remembering a language preference and, more controversially, tracking people across sites. This article explains what a cookie is, how sessions are built on top of it, and how to manage both sensibly.

How a cookie turns into a logged-in session

A cookie is a small piece of text that a server asks the browser to store. The server includes a Set-Cookie header in its response; the browser saves the name, value and a few attributes; and on every later request to the same site the browser sends the cookie back in a Cookie header. That is the entire mechanism. The cookie’s meaning comes from what the server chooses to put in it.

The attributes matter:

• Domain and Path limit which requests carry the cookie.
• Expires / Max-Age decide whether the cookie survives closing the browser (a persistent cookie) or vanishes at the end of the session (a session cookie).
• Secure means the cookie is sent only over HTTPS.
• HttpOnly hides the cookie from JavaScript, so a script injected into the page cannot steal it.
• SameSite controls whether the cookie is sent when the request originates from another site. Lax or Strict blocks many cross-site request forgery attacks; None allows cross-site use and is what third-party tracking relies on.

From cookies to sessions

When you log in, the server does not store your password in a cookie. It creates a session: a record on the server (or a signed token) that says “this identifier belongs to user 4821, authenticated at 10:32, expires in two weeks”. The identifier, a long random string, is placed in a cookie. On each request the server looks up the identifier and knows who you are.

This has an important consequence: whoever holds the session cookie is you as far as the site is concerned. Stealing a session cookie bypasses the password and often two-factor authentication, which is why Secure, HttpOnly and short lifetimes exist, and why logging out on a shared computer matters: logging out invalidates the session on the server, so a copied cookie stops working.

First-party and third-party cookies

A first-party cookie belongs to the site in the address bar. A third-party cookie belongs to a different domain whose content, such as an advertisement, an embedded video or an analytics script, is loaded inside the page. If the same advertising domain is embedded on thousands of sites, its cookie lets it recognise the same browser everywhere and build a profile of visited pages. This is the tracking that privacy regulation targets and that browsers increasingly block or partition by default.

Sites that show a “cookie banner” are usually asking for consent to set third-party or analytics cookies. Cookies that are strictly necessary for a service to work, such as the login session or a shopping basket, do not require consent under most rules.

Everyday examples

• “Remember me” sets a long-lived session cookie instead of a browser-session one.
• A basket that survives closing the tab is a persistent first-party cookie holding a basket identifier.
• Being logged out of everything after clearing cookies is the sessions disappearing along with their identifiers.
• Seeing an advert for something you viewed elsewhere is a third-party cookie linking the two visits.
• A site remembering your language without an account is a simple preference cookie.

Managing cookies without breaking logins

For users:

• Block third-party cookies in the browser settings; almost nothing you rely on will break.
• Log out rather than just closing the tab on shared devices, so the session is invalidated server-side.
• Clearing cookies for a single problem site is usually enough; wiping all of them logs you out everywhere.
• Use separate browser profiles or containers to keep work, personal and shopping identities apart.

For site owners:

• Set Secure, HttpOnly and SameSite=Lax (or Strict) on session cookies.
• Regenerate the session identifier at login and invalidate it at logout and on password change.
• Keep sessions as short as usability allows, and offer a “log out everywhere” option.
• Store only an identifier in the cookie; keep user data on the server.
• Show a consent banner only if you actually set non-essential cookies, and make declining as easy as accepting.

Frequently asked questions

Are cookies dangerous?

Cookies themselves are inert text. The risks are misuse: tracking without consent, and theft of session cookies through insecure sites or malicious extensions.

What is local storage, and is it the same?

Local storage is another browser storage area that scripts can use. Unlike cookies it is not sent automatically with requests, so it cannot identify you to the server by itself, but scripts can read it and send it along.

Why am I asked about cookies on every site?

Because consent is stored in a cookie, and the site can only read its own. Blocking third-party cookies and using a browser with tracking protection does not remove banners, but it does reduce what they can do.

A cookie is a note the site asks your browser to carry back on every visit; the session is what the site remembers about that note.

In short: Cookies give a stateless web a memory, and sessions use them to keep you logged in. First-party cookies are mostly essential; third-party cookies are mostly tracking. The right attributes on the server and the right settings in the browser keep the useful parts and limit the rest.