What rejecting cookies actually does
You’ve clicked “reject all” a thousand times. The banner disappears, the page loads, and you move on with a vague sense that you’ve done something. But what actually changed? Which requests stopped firing, and which ones didn’t even notice you were there? Understanding the mechanics makes the button a lot less mysterious, and a lot less magical.
The button and what it’s wired to
A cookie banner is a consent management layer sitting on top of a page. When it loads, it usually blocks or delays third party scripts (ad tags, analytics pixels, social widgets) from firing until you make a choice. “Reject all” tells that layer to keep those specific scripts from loading, or to load them in a stripped down mode that doesn’t set identifiers.
Here’s the part people miss: the banner is a website feature, not a browser feature. Its behavior depends entirely on how the site’s developers wired it up. A well built consent manager (the kind required for compliance in places like the EU) genuinely stops the tagged scripts. A poorly built one, or one that’s flat out non-compliant, might reject the cookies but still let the script load and phone home anyway. There’s no browser-level enforcement checking that the site kept its promise. You’re trusting the site’s implementation, not a technical guarantee.
First party cookies vs third party cookies
Cookies aren’t one thing. A first party cookie is set by the domain you’re actually visiting, usually to remember your login, your cart, or your language setting. A third party cookie is set by a different domain, typically an ad network or analytics company, embedded via a script or pixel on the page you’re viewing. Ad networks used third party cookies to recognize the same browser across many unrelated sites and stitch together a browsing history.
When you reject all, you’re mostly stopping third party cookies from ad and tracking networks. Many sites still set some first party cookies regardless, because those are often needed for the site to function (session state, CSRF tokens, remembering that you already answered the cookie banner). Rejecting tracking cookies isn’t the same as rejecting all cookies in the literal sense, even though the button says “all.”
What “reject all” actually turns off
When it works as intended, rejecting stops:
- Third party ad tracking cookies that follow your browser across sites to build an ad profile
- Cross site retargeting pixels (the ones that show you the shoes you looked at three days ago)
- Some analytics scripts, if the site scoped its consent manager to block them too
That’s a real reduction in the amount of cross site correlation happening through cookies specifically. If a site’s implementation is solid, an ad network that relies purely on third party cookies genuinely loses the thread on you for that session.
What it doesn’t touch
This is the part worth sitting with, because it’s where the false sense of completion creeps in.
Your IP address. Every request you make, cookie or not, carries your IP address to the server. That’s how the internet routes traffic back to you. Rejecting cookies does nothing to this. A site can still see which network you’re connecting from and roughly where that network is based.
Browser fingerprinting. Trackers can identify a browser without ever setting a cookie, by reading a combination of signals your browser exposes: screen resolution, installed fonts, timezone, GPU rendering quirks (canvas fingerprinting), audio stack behavior, and dozens of smaller configuration details. None of that requires storing anything on your device. It’s read passively from what your browser already discloses on every page load. Rejecting a cookie prompt has no effect on this, because there was never a cookie involved to reject.
Server side and account based tracking. If you’re logged into a service, that service doesn’t need a cookie to know it’s you. It knows because you authenticated. Cookies are one mechanism among several for maintaining that session (tokens in local storage or passed via headers do similar jobs), and blocking cookies from an ad network has nothing to do with a site’s own logged in tracking of your activity.
Cross device and email based matching. Ad companies increasingly match identity using hashed email addresses, phone numbers, or loyalty program data submitted directly by advertisers, rather than relying on a cookie planted in your browser. This is sometimes called a “walled garden” approach precisely because it doesn’t depend on cross site cookies at all.
Non-compliant scripts. As mentioned above, if a site’s consent tooling is broken or dishonest, clicking reject doesn’t guarantee the underlying script actually stops running. The button reflects your preference; whether the site honors it is a separate, unverifiable question from where you’re sitting.
Fingerprinting is the workaround that doesn’t ask permission
It’s worth dwelling on fingerprinting a bit longer because it’s the direct technical answer to “why doesn’t rejecting cookies just fix this.” Cookie based tracking requires storing a unique ID on your device and reading it back later. That’s a two step process a user can interrupt, which is exactly why regulators built consent requirements around it.
Fingerprinting flips the order. Instead of storing an ID, the tracker computes one on the fly from characteristics your browser was going to reveal anyway as part of normal page rendering. Two people with the same browser version, same OS, same screen size, same installed extensions, and same timezone will look more alike; someone with an unusual combination of settings stands out more, which paradoxically makes rarer configurations easier to track. There’s no consent prompt for this because, legally and technically, nothing is being “stored” on your device in the way cookie law is written around. This is why privacy-focused browsers and extensions that specifically target fingerprinting (by standardizing what your browser reports, or blocking script access to certain APIs) address a different problem than a cookie banner does.
Why sites still work when you reject
People sometimes worry that rejecting cookies will break a site. Mostly it doesn’t, because the cookies essential to function (keeping you logged in, remembering your cart) are usually first party and exempt from the reject action, or at least treated as “strictly necessary” and not offered as optional in the first place. What tends to change after rejecting is the ads become less personalized and some embedded content (a YouTube video, a social share widget) might load in a limited or delayed mode, since those widgets often rely on the same third party cookies to function fully.
A more realistic mental model
Think of “reject all cookies” as closing one specific door in a house with several doors. It’s a real door, and closing it stops a specific, well understood kind of traffic: cross site ad and analytics cookies. It does not lock the house. IP based identification, fingerprinting, and first party tracking by the site you’re actually using are separate doors that a cookie banner was never designed to touch, because they’re not cookies.
This isn’t a reason to skip the button. Reducing cross site ad tracking is a real, measurable improvement in your threat model if your goal is “stop being followed by retargeting ads across unrelated sites.” It’s just not a privacy solution on its own, and no single click, extension, or app gets you there either. People who want to reduce fingerprinting look at browser configuration and script blocking. People worried about IP based location look at network level tools. People worried about a specific service’s data practices generally have to read what that service actually does with your account data, since no browser setting can override that. Each of those is a different problem with a different mechanism, and it helps to know which one you’re actually solving when you click.
If you want the rest of that picture, from how fingerprinting is actually measured to what IP based tracking can and can’t infer about you, that’s the kind of thing we walk through in detail on the channel and the site.
Explore more breakdowns like this one on the The Privacy Wire homepage.