You visit an online bookstore, spend a few minutes browsing, then close the tab and shut your laptop. The next morning you open the same site in a fresh browser window and it picks up where you left off. Your cart is intact. You're still logged in. The site greets you by name.
None of this required magic. It required the browser to send a small piece of stored data back to the server, and the server to recognise what it meant. The mechanisms behind that recognition are worth understanding, both because they explain a lot about how the web works and because the same machinery that remembers your shopping cart can also be used to track you across sites you've never intentionally signed into.
Cookies: The Foundation
The most direct answer to how websites remember you is cookies. A cookie is a small text value that a server sends to your browser, which your browser stores and then returns with every subsequent request to the same domain.
When you first land on a site, the server can instruct your browser to store a cookie by including a Set-Cookie header in the HTTP response. From that point on, the browser automatically includes that cookie in the Cookie header of every request it makes to that domain including requests after you've closed the browser, opened it again, and navigated back to the site.
The critical distinction is between session cookies and persistent cookies. A session cookie has no expiration date. Browsers are supposed to delete it when the session ends, which in practice usually means when all windows for that browser are closed. A persistent cookie includes an expiration date set by the server, which tells the browser to keep the cookie until that date, regardless of how many times you close and reopen the browser.
When a site says "remember me for 30 days," it's setting a persistent cookie. When you log back in a week later and the site still knows who you are, that cookie is why. The server assigned you a session identifier essentially a long, random token stored it in a cookie, and associated it with your account in its database. Your browser presents the token, the server looks it up, and you're in.
Local Storage and Why It's Different
Cookies are not the only way browsers store data from websites. The Web Storage API provides localStorage and sessionStorage, both of which let sites store larger amounts of data on the client side without that data being automatically included in HTTP requests.
sessionStorage is cleared when the browser tab is closed. localStorage persists until explicitly cleared by the site's JavaScript or by the user. A site could theoretically use localStorage to store an identifier and then read it back with JavaScript on the next visit, even after a browser restart.
The important difference from cookies: localStorage data is never sent to the server automatically. The site has to use JavaScript to read it and then decide whether to include it in a request. This makes it less convenient for authentication but it's sometimes used alongside cookies for other forms of site state, preferences, or identifiers.
How Login Sessions Actually Work
Recognising a browser and verifying a user's identity are two different things, and it's worth being precise about the distinction.
A session cookie on its own identifies a browser instance, or more accurately a token stored in that browser. If someone else uses the same computer without clearing cookies, the site may treat them as you. This is why logging out matters on shared devices logging out typically instructs the server to invalidate the session token, so presenting the cookie again does nothing useful.
When a site recognises you as a person across visits showing your order history, your saved preferences, your name it's because the token stored in the persistent cookie maps to an authenticated session in the server's database. The browser proved it had the right token; the server concluded that whoever holds that token is the account's legitimate owner.
This is also why stolen cookies are serious. If an attacker obtains a valid session cookie, they can replay it and be treated as you without needing your password. Session fixation and cookie theft via cross-site scripting are real attack vectors for exactly this reason.
Fingerprinting: Recognition Without Storage
Cookies and local storage require the browser to actively hold and return data. Browser fingerprinting works differently: the website collects characteristics of your browser and device, combines them, and uses the result to estimate whether you've visited before.
These characteristics include things like your browser version, operating system, installed fonts, screen resolution, timezone, language settings, graphics rendering behaviour (via the Canvas and WebGL APIs), and dozens of other attributes that can be queried through standard JavaScript APIs. Individually, each attribute is unremarkable. Combined, they can form a profile that is relatively unusual within the population of browsers visiting that site.
The key word is "relatively." Fingerprinting is probabilistic, not definitive. Two people with identical hardware and browser configurations will produce the same fingerprint. A single person who updates their browser, changes their system fonts, or switches operating systems will produce a different one. Fingerprints are not stable identifiers they shift over time and they are not guaranteed to be unique.
What fingerprinting is useful for, in practice, is fraud detection (flagging a login from an unusual browser environment), analytics, and cross-visit tracking where the goal is probabilistic pattern matching rather than certain identification. The EFF's Cover Your Tracks project demonstrates how distinguishable most browser configurations are in practice.
Third-Party Tracking and Its Decline
The web has historically relied heavily on third-party cookies for cross-site tracking. The mechanism is conceptually straightforward: a site embeds a resource an image, a script, an analytics beacon from an external domain. The browser loads that resource and, in doing so, sends along any cookies associated with that external domain. If the same tracker is embedded across thousands of sites, it can observe and record much of your browsing history.
Modern browsers have largely moved against this. Safari has blocked third-party cookies by default since 2017. Firefox followed. Chrome has been working toward the same outcome, though the timeline has shifted more than once. When third-party cookies are blocked, the embedded tracker can no longer set or read persistent identifiers across sites. This is a meaningful restriction, though fingerprinting and workarounds like link decoration passing identifiers in URL parameters partially fill the gap.
First-party cookies, set by the domain you're actually visiting, are not affected by third-party cookie restrictions. The shopping site you visit directly can still remember you indefinitely through its own persistent cookies.
What Private Browsing Actually Does
Private or incognito mode is widely misunderstood. What it typically does: cookies, site data, and browsing history are stored only for the duration of the private session and discarded when all private windows are closed. From your browser's perspective, each private session starts clean.
What it does not do: hide your activity from websites you visit, your internet service provider, or your employer's network. Websites you visit in private mode can still read your IP address, set cookies for the duration of the session, and perform fingerprinting. Your browsing remains visible to anyone who can observe network traffic.
Within a single private browsing session, a site can absolutely track your movement through its pages using session cookies, just as it would in a normal browser session. The privacy benefit is local and temporal: no persistent record is kept on your device after the session ends, and sites cannot read cookies from your ordinary browsing profile.
Staying in Control
For most people, the practical implications are straightforward.
Cookies from sites you actively use and trust are largely fine. Clearing cookies periodically or using browser settings to limit cookie lifetimes reduces persistent tracking. Browser extensions like uBlock Origin restrict trackers and their associated cookies without affecting the sites you're actually trying to use.
The more durable form of tracking is fingerprinting, because it doesn't rely on any stored data you can clear. Browsers like Firefox and Brave include fingerprinting resistance measures that reduce or randomise some of the more distinctive attributes. These protections are imperfect but meaningful.
The most dangerous form of recognition isn't tracking it's session cookie theft. Keeping your browser updated, using sites over HTTPS, and understanding that logging out invalidates server-side sessions (not just local cookies) are the controls that actually matter for security.
When you return to that bookstore the morning after closing your browser, the site hasn't remembered you through anything mysterious. It set a persistent cookie the last time you visited, your browser stored it faithfully, and your browser sent it back automatically when you returned. The server matched the token, found your account, and resumed where you left off.
The mechanisms are mundane once you understand them. What makes them interesting is that the same infrastructure serves very different purposes: it's what keeps you logged in to your email, what lets your shopping cart survive a browser restart, and what allows advertisers to follow your activity across the web. The difference is mostly in who set the cookie, what it encodes, and how long it's meant to last.
