../courses.php

The Browser's Role

BROWSER

90

Cookies And Browser Memory

Why a stored cookie can keep working in one browser tab and stop working in a different one.

A user logs into a site successfully in one browser tab. Opening the exact same site in a brand-new private or incognito window shows the user as logged out entirely, even on the very same computer, moments later. Nothing about the login itself failed. Why would the exact same site, on the exact same device, treat these two windows as though they belonged to two different people?

A cookie is stored by, and only readable by, the specific browsing context that received it, and a private or incognito window is deliberately kept separate from a browser's regular storage, including its cookies. The login cookie set in the regular window was never copied into the private window at all, so the private window genuinely has no proof of that login to send back, which is exactly why the site treats it as a fresh, unrecognized visitor, even though it is the same site on the same device only moments later.

A cookie is a small piece of text a server asks the browser to store, using a Set-Cookie header in a response, and the browser then automatically resends on later requests to that same site.

A cookie is stored per browser, and within a browser, per separate browsing context. A private or incognito window deliberately keeps its own storage separate from a browser's regular one, specifically so nothing carries over between the two.

A cookie commonly includes attributes beyond just its value, such as an expiration time, after which the browser stops sending it at all, treating it as no longer valid.

A server reading a cookie value has no way to verify on its own that the value genuinely represents what it claims to, unless the server specifically designed that value to be checkable, such as by making it hard to guess or by checking it against something stored on the server's own side.

Clearing a browser's stored cookies removes this kind of memory entirely. A site that previously recognized a returning visitor through a cookie has no other way to recognize that same visitor once the cookie is gone, unless some other mechanism was specifically built for that purpose.

Setting a cookie, then sending it back automatically on a later request

This Set-Cookie header, sent once by the server, is what causes the browser to begin storing session_id=abc123 at all. Nothing about the browser's normal behavior stores a cookie unless a server explicitly asks for it this way.

Max-Age=3600 tells the browser to stop considering this cookie valid, and stop resending it, after 3600 seconds from when it was set. After that point, a later request to the same site would no longer include this cookie at all.

The browser attaches the Cookie header on the later request automatically, without anything in the page or any script needing to ask for it again, because it was previously told to store and resend exactly this value to this site.

A private window, or an entirely different browser, never received the original Set-Cookie response, so it has nothing stored to resend at all. This is not a failure, it is the expected, deliberate result of cookies being scoped to one specific storage area.

The server reads session_id=abc123 back and checks it against whatever it stored when that session was originally created. The cookie itself is just a value being passed back and forth, the actual checking happens entirely on the server's side.

A private window's separate storage is a deliberate design choice, not a bug

A private or incognito window is specifically built to avoid sharing cookies, history, and other stored data with a browser's regular browsing. Logging out unexpectedly in a brand-new private window is the intended, designed behavior, not a sign that anything failed.

An expired cookie stops being sent with no error or warning

Once a cookie's Max-Age has passed, the browser simply stops including it in later requests. There is no error message or visible signal that this happened, the request that used to carry proof of a session now goes out exactly as if that proof had never existed.

The browser stores and resends a cookie's value with no understanding of what it means

The browser treats session_id=abc123 as an opaque piece of text to store and resend exactly as given. Whether that value still corresponds to a real, valid session is something only the server can determine, by checking it against its own records.

Clearing cookies removes a site's only way of recognizing a returning visitor, unless something else was built for that purpose

A site relying entirely on a cookie to recognize a returning, logged-in visitor has no fallback once that cookie is cleared. The visitor is indistinguishable, from the server's point of view, from someone who has genuinely never visited before.

A cookie set on one site is not sent to a different site, even one linked from the first

A cookie is scoped to the specific site that set it. Clicking a link from one site to a completely different one does not carry that first site's cookies along, which is part of why logging into one site does not automatically log a user into an unrelated one.

Setting a cookie with no expiration at all

Setting a cookie with an explicit, reasonable expiration

When an AI tool describes a login flow, three things are worth checking. First, does it correctly treat a private or incognito window as having genuinely separate cookie storage, rather than as a bug when a login does not carry over. Second, does a described cookie include a deliberate, reasonable expiration rather than being set to last indefinitely with no thought given to it. Third, does the explanation correctly describe the server, not the browser, as the side responsible for verifying what a cookie's value actually means.

Log into a real site in a regular window, then open the same site in a private window, and confirm the login does not carry over.

Set Max-Age to a very small number, such as 5, wait past that time, and reload a page that depends on that cookie to see the effect.

Clear a site's stored cookies manually through your browser's settings, then reload a page that previously recognized you as logged in.

Write a Set-Cookie header with no Max-Age at all, then look up what your specific browser does with a cookie set this way by default.

Visit two unrelated sites in sequence, and confirm, using your browser's developer tools, that a cookie set by the first one is not sent as part of any request to the second.

Treating a login that does not carry over into a private or incognito window as a bug, rather than as the intended, designed separation of storage.

Setting a cookie meant to represent a temporary session with no expiration at all, rather than an explicit, reasonable Max-Age.

Assuming the browser itself verifies what a cookie's value means, rather than only storing and resending it exactly as given.

Assuming clearing cookies has no effect on a site that relies on them to recognize a returning visitor, when it removes that recognition entirely.

Assuming a cookie set by one site is available to a different site simply because a link connects the two.

You can now explain why cookies are stored separately per browsing context, and why a private or incognito window behaves as a genuinely new, unrecognized visitor by design. You can also explain what a cookie's expiration actually controls, and why the browser itself has no understanding of what a cookie's value means, only the server that set it does.