What Are Cookies and How Do They Work?

Cookies aren't inherently bad, and third-party cookies never actually disappeared the way Chrome once promised. Here's what they are, how they work under the hood, and what's actually tracking you in 2026.

Published Jul 2, 2026
Updated Jul 2, 2026
10 min read
Share
Illustration of a browser cookie file being set and returned between a browser and a website

Cookies get talked about like they're something to be afraid of. Mostly, they're not. A cookie is what keeps you logged into your email between page loads, remembers what's in your shopping cart, and keeps a site in your preferred language. The tracking side of cookies is real too, but it's a specific use of the same basic tool, not something separate.

This covers what a cookie actually is, how the mechanism works, and a few things about the current state of cookie tracking that a lot of older articles online still get wrong.

A cookie is a small piece of text a website asks your browser to store, then sends back to that same website on later visits. That's the whole concept. It's typically a handful of characters, well under a kilobyte, structured as a name and a value, plus a few settings that control where and how long it applies.

Cookies were invented in 1994 by Netscape developer Lou Montulli, specifically to solve the shopping cart problem. Without some way to remember state between page loads, an early e-commerce site had no way to know that the person clicking "checkout" was the same person who'd clicked "add to cart" two pages earlier. HTTP itself has no memory. Cookies were the patch that gave it one.

How cookies actually work

When your browser requests a page, the server can include a Set-Cookie header in its response. Your browser stores whatever that header specifies, then automatically attaches it back to future requests to that same site using a Cookie header. No JavaScript required for the basic mechanism, though plenty of sites also set cookies via JavaScript for more flexibility.

A handful of attributes control exactly how a cookie behaves. These matter more than most people realize, since they're what determines whether a cookie is relatively contained or can follow you around the web.

Attribute What it controls
Domain Which site(s) the cookie gets sent back to
Path Which part of the site the cookie applies to
Expires / Max-Age How long the cookie survives (missing = deleted when the browser closes)
Secure Only sent over HTTPS, never plain HTTP
HttpOnly Hidden from JavaScript, reduces theft risk from cross-site scripting
SameSite Controls whether the cookie is sent on requests coming from other sites (Strict, Lax, or None)

First-party vs third-party cookies

This distinction is what the whole "cookie tracking" conversation is actually about.

First-party cookie

Set by the site you're actually visiting. Used for logins, shopping carts, language settings, and basic analytics the site runs on itself.

Third-party cookie

Set by a domain other than the one in your address bar, usually an ad network or analytics company whose script is embedded on the page.

The tracking mechanism is straightforward once you see it. An ad network's script gets embedded on thousands of unrelated sites. Every time your browser loads a page with that script on it, the script sets or reads a cookie under the ad network's own domain, not the site you're visiting. Since the same cookie gets sent back on every site running that script, the ad network can piece together a single browsing history across all of them, even though none of those sites belong to the same company or ever shared data with each other directly. Our guide to targeted advertising walks through what happens to that browsing history once it's assembled.

A session cookie has no expiration set, so it disappears when you fully close your browser. A persistent cookie has an actual expiration date or max-age value, sometimes set years out, and survives being closed and reopened. That's the technical distinction behind a "remember me" checkbox on a login form.

Beyond that, cookies typically get sorted by purpose, which is also the categorization most cookie consent banners use: strictly necessary cookies (the site can't function without them, like login sessions), functional cookies (remembering preferences, not essential but useful), analytics cookies (measuring traffic and behavior), and marketing/advertising cookies (the ones behind targeted ads, usually third-party). Everything technically works the same way. The category is really just a description of intent.

Did third-party cookies actually go away?

Depends entirely on which browser someone's using, and this is the part where a lot of articles you'll find online are simply outdated.

Chrome's third-party cookie plan, in short

Google originally aimed to phase out third-party cookies in Chrome by 2022, then pushed the deadline back repeatedly through 2024 and 2025. In July 2024, the full removal plan was dropped in favor of a "user choice" prompt instead. In April 2025, Google confirmed it wouldn't build that prompt either, and would simply keep the existing cookie controls in Chrome's settings. By October 2025, Google formally retired most of the Privacy Sandbox APIs it had built as cookie replacements, citing low industry adoption. As of 2026, third-party cookies remain on by default in Chrome.

Safari and Firefox never waited for Google. Safari's Intelligent Tracking Prevention has blocked third-party cookies by default since Safari 13.1, back in March 2020. Firefox's Enhanced Tracking Protection blocks known tracker cookies by default too. Chrome is the outlier that still allows them, which matters because Chrome is also the browser most people actually use.

One genuinely useful piece did survive from Google's effort: CHIPS (Cookies Having Independent Partitioned State). A cookie can be marked Partitioned, which means the browser keeps a separate copy of it for every top-level site it's embedded on, instead of one shared copy that follows you everywhere. The same ad network's cookie on Site A and Site B become two isolated cookies rather than one that links your visits together. It's a quieter, more technical fix than the full deprecation Google originally promised, but it's real and it's already shipped.

Zombie cookies and other ways tracking survives

Clearing your cookies doesn't necessarily clear everything a site could use to recognize you. Older tracking techniques, sometimes called zombie cookies or supercookies, stored a copy of an identifier somewhere outside the normal cookie jar specifically so it could survive a "clear cookies" click. Flash's local storage was the most notorious version of this, and it mostly died along with Flash itself in 2020. The same underlying idea still applies to localStorage, IndexedDB, and other browser storage APIs, none of which get touched by a browser's basic "clear cookies" button. Clearing "all site data," not just cookies specifically, closes most of that gap.

The technique that doesn't rely on storing anything at all is browser fingerprinting. Instead of setting an identifier and reading it back later, a fingerprinting script measures characteristics your browser exposes anyway, screen resolution, installed fonts, GPU rendering quirks, and combines them into an identifier that's often unique enough to recognize you without a single cookie involved. It's a meaningfully different problem from cookie tracking, worth understanding on its own; you can see what your browser currently exposes with our browser fingerprint test.

Does a VPN stop cookie tracking?

No, and this trips people up constantly. A VPN changes your network identity, your IP address, and which server your traffic appears to come from. Cookies are stored inside your browser, on your device, completely independent of your network connection. Turning on a VPN doesn't touch, delete, or block a single cookie already sitting in your browser.

It's genuinely useful to think of these as two separate tracking layers that happen to get bundled together in people's minds. A VPN addresses the network layer: who can see your IP and where your traffic is routed. Cookies (and fingerprinting) operate at the browser layer: what a site can learn and remember about the browser itself, regardless of which network it's connecting from. A VPN with zero cookie management will still leave you fully trackable by cookies. Clearing cookies with no VPN will still leave your IP address visible. Neither one substitutes for the other.

How to actually manage cookie tracking

01
Block third-party cookies at the browser level
Chrome, Firefox, and Edge all have a setting to block third-party cookies specifically, without breaking most first-party logins and shopping carts. In Chrome it's under Settings → Privacy and security → Third-party cookies.
02
Use a browser with tracking protection on by default
Firefox with Enhanced Tracking Protection set to Strict, or Safari with its default ITP settings, block a meaningful chunk of third-party tracking cookies automatically, no configuration required.
03
Clear "all site data," not just cookies, periodically
This catches localStorage and IndexedDB-based tracking that a cookies-only clear leaves behind. Most browsers offer this as a separate, broader option in the same privacy settings menu.
04
Know what private browsing actually clears
A private or incognito window doesn't save cookies after you close it, but it's not invisible while it's open, and it does nothing to stop fingerprinting. Our guide to what incognito mode actually does covers the gap between what people assume and what it really protects.
05
Treat a VPN and cookie management as separate tasks
Run both if network-level and browser-level tracking both matter to you. Neither one is a substitute for the other, and a lot of privacy setups only ever address one of the two.

Frequently Asked Questions

Mostly overhyped, for the plain kind at least. A cookie is just a small piece of text. It can't install malware, read your files, or do anything to your device beyond storing and returning a bit of data to the site that set it. The privacy concern isn't the cookie itself, it's what a company does with the data it collects using cookies as the identifier, especially when that identifier follows you across dozens of unrelated sites. Cookies that keep you logged in or remember your cart are the same technology as cookies used for cross-site ad tracking. The mechanism is identical. The use case is what makes one benign and the other worth caring about.

Yes, generally, and that's expected. Most sites use a cookie to store your session token, the piece of data that proves to the server "this browser is logged in as this account." Delete that cookie and the server has no way to recognize you anymore, so you'll need to sign back in. This is normal and not a sign anything went wrong. It's also why sites you visit often will nudge you to "stay signed in," which just sets a longer-lived cookie instead of a short session one.

No, not in Chrome, which is the browser most people use. Google spent years promising to remove them and ultimately backed off the plan entirely by late 2025. They're still on by default in Chrome today. Safari and Firefox are a different story: both have blocked third-party cookies by default for years already, well before Google even attempted it. So the honest answer depends entirely on which browser someone is using, which is a more useful way to think about it than a flat yes or no.

A session cookie has no expiration date set, so your browser deletes it the moment you close the browser entirely (not just the tab). A persistent cookie has a specific expiration date or a max-age value written into it, so it survives being closed and reopened, sometimes for years. In practice, a "remember me" login checkbox is the difference between the two: unchecked, you get a session cookie and have to log in again next time; checked, you get a persistent one that keeps you signed in.

Yes, and this is the part most cookie-focused advice leaves out. Blocking cookies stops the most common tracking method, but not the only one. Sites can still fingerprint your browser using dozens of small signals (screen size, installed fonts, GPU rendering quirks, and more) that don't require storing anything on your device at all. Browser fingerprinting has actually become more relevant precisely because privacy-conscious users blocked or cleared their cookies, pushing some tracking companies toward a method that doesn't rely on cookies existing in the first place. You can check what your own browser currently exposes with our browser fingerprint test.

A supercookie (sometimes called a zombie cookie) is tracking data stored somewhere other than the normal cookie jar, specifically so it survives a regular "clear cookies" action. Older techniques stashed a copy of the identifier in Flash's local storage or in cached ETags, then used it to silently regenerate a deleted cookie the next time you visited. Flash is gone now, which killed the most notorious version of this, but the same idea lives on using localStorage, IndexedDB, and other browser storage APIs that a standard cookie-clearing button doesn't always touch. Clearing "all site data" or "all browsing data," rather than just cookies specifically, closes most of that gap.