Third-party cookies are dying. What replaced them is worse.

Every privacy advocate has spent the last five years cheering the death of third-party cookies. Safari killed them in 2020. Firefox killed them in 2020. Chrome's deprecation finalizes in 2026. The headline reads like a win for users. The reality is that ad-tech spent those five years building a replacement stack that is harder to block, harder to see, and in most meaningful ways more invasive than cookies were. The surveillance did not retreat. It shifted layers.

What third-party cookies were

A third-party cookie was a small piece of data set by a domain different from the one the user visited. Visit example.com, a script from tracker.net runs, tracker.net sets a cookie in the user's browser. Every subsequent site that embeds any tracker.net code sends that cookie back, letting tracker.net build a cross-site profile tied to the cookie's unique value. This mechanism powered programmatic advertising from roughly 1998 through 2020.

Third-party cookies had three properties that made them relatively easy to regulate:

• Visible. Any user could open DevTools and see every cookie set on a page, including from which domain.
• Controllable. Browsers had settings to block third-party cookies with a checkbox. Users who cared could turn them off.
• Regulatable. GDPR's cookie banner requirement (2018) forced sites to disclose third-party cookies and request consent. Imperfect enforcement, but a real legal hook.

Why they are dying

Safari disabled third-party cookies by default via Intelligent Tracking Prevention (ITP) in 2020. Firefox did the same via Enhanced Tracking Protection the same year. Chrome announced deprecation in 2020, delayed several times, and the final rollout is completing through 2026. Once Chrome's transition finishes, third-party cookies will be blocked by default in every major browser used on the modern web.

The catalysts were regulatory pressure (GDPR, ePrivacy Directive, California's CCPA), browser-vendor competition on privacy as a feature, and a genuine user backlash after several high-profile tracking scandals (Cambridge Analytica, adjacent disclosures). Safari and Firefox moved first because their business models don't depend on ad revenue. Chrome moved last — and reluctantly — because Google's business does.

What replaced them

Ad-tech had roughly five years' warning and spent them aggressively building alternatives. The replacement stack splits into four categories.

1. Browser fingerprinting

The biggest single category. A browser fingerprint is a unique ID computed from dozens of device-level signals: canvas rendering hash, audio context hash, WebGL renderer, installed fonts, screen dimensions, timezone, language, TLS signature, hardware concurrency. Combined, these produce an identifier unique to individual devices, stable across sessions, and usable across sites without any cookie.

Fingerprinting is strictly worse for users than third-party cookies were. Cookies could be cleared with a button press; fingerprints persist until you replace your hardware. Cookies were visible in DevTools; fingerprints are computed client-side and only the hash is transmitted. Cookies had GDPR cookie banners; fingerprinting operates in an unregulated gray area most enforcement agencies have not addressed. See snitchtest.com/the-dossier for the technical deep-dive.

2. Email-hash IDs (Unified ID 2.0 and friends)

When a user logs in to a publisher site with their email, the site hashes the email (typically SHA-256) and passes the hash to ad-tech partners. The hash serves as a cross-publisher identifier: every site the user logs into with the same email can correlate visits through the shared hash.

Unified ID 2.0 (The Trade Desk + industry consortium), LiveRamp's RampID, and Google's Encrypted Signals are the best-known implementations. The system's pitch is "consent-based" because the user technically provides their email. In practice, most users don't realize the hash serves this purpose, and once an email hash is in the graph, it links every logged-in session on every participating site for the life of that email address — typically a decade or more.

Compared to cookies: harder to reset (changing email is more friction than clearing cookies), longer-lived, and legally more defensible because the consent was opt-in at signup.

3. Google's Privacy Sandbox (Topics API, Protected Audience)

Google's answer to the cookie death. The Topics API assigns each browser 3–5 "interest topics" per week from a fixed taxonomy (~350 categories). Sites can request the current topics; the response enables interest-based targeting without cross-site identifiers. Protected Audience API (formerly FLEDGE) handles remarketing — interest groups are stored locally in the browser; auctions run locally; the ad served is determined without the advertiser knowing the specific user.

The intent is clearly better than third-party cookies. On-device data, limited topic taxonomy, no personal identifiers in the request. Regulators (UK Competition and Markets Authority, EU) have flagged concerns that Privacy Sandbox primarily benefits Google's ad business by replacing open-web identifiers with Chrome-controlled ones. Publishers and advertisers have been slow to adopt the APIs because the targeting precision is meaningfully lower than cookies allowed.

For users: Privacy Sandbox is an improvement over cookies in specific ways but still constitutes tracking. Users who care about strict privacy should not rely on Privacy Sandbox as a defense — it's at best a harm reduction mechanism for users who are going to be tracked anyway.

4. Server-side user IDs

The simplest replacement: when a user is logged in, the server records their user ID against their activity. Analytics happens on the server. Data flows between partners via server-to-server APIs that never touch the browser's cookie store. Every major publisher and every major ad-tech vendor now runs some form of this as their primary tracking infrastructure.

Server-side tracking is invisible to client-side defenses. A browser fingerprint defense does not block it. A uBlock Origin rule does not block it. The only defenses that work are (a) not logging in, or (b) not being the same user across sites, which is impossible in practice for most services people actually use.

Comparison of the four replacements

The honest assessment

Third-party cookies were a bad tracking mechanism — easy to block, visible, regulatable. The things that replaced them are mostly worse mechanisms for users. Fingerprinting moved the surveillance to a layer that users cannot see and cannot reset. Email-hash IDs lock tracking to your real-world identity for decades. Server-side IDs removed the client-side choke point where defenses existed. Privacy Sandbox is genuinely better in some ways but still tracking, and its structure consolidates control into Google's hands.

The regulatory bet five years ago was that killing third-party cookies would substantially reduce tracking. The actual outcome is that tracking continued at approximately the same volume with different, harder-to-see mechanisms. ADBLOAT's tracker-fixture measurements from 2022 to 2026 show the total bytes per pageview shipped by ad-tech has increased, not decreased, across that window — even as cookie-based tracking became less common.

What actually works in 2026

Defenses that move the needle against the replacement stack, in decreasing order of leverage:

1. Browser with fingerprint defense. Brave (Strict Shields) or Firefox (privacy.resistFingerprinting). This defeats most fingerprinting at the client.
2. Content blocker at the URL level. uBlock Origin with its standard block lists catches the majority of known tracker scripts before they run. This complements fingerprint defenses because it prevents the fingerprinting script from loading at all.
3. DNS-layer blocker. Pi-Hole, AdGuard Home, NextDNS. Catches known tracker domains at the network level. Does not catch first-party trackers or fingerprint-only flows, but removes a large volume of ad-tech requests. Verify coverage at piholekiller.com.
4. Not logging in where possible. If a site's tracking is server-side behind a login, the only defense is not logging in. Use guest checkout when offered. Use a mail alias service (SimpleLogin, AnonAddy) for the logins you do need, so your primary email hash doesn't spread through the UID2 graph.
5. Keep a separate browser or profile for high-trust activities. Banking and work accounts on a clean browser; general browsing on a hardened-but-used browser. Cross-linkage through shared fingerprints becomes harder.

No single layer defeats the full replacement stack. The combination raises the cost of accurate cross-site identification enough that most ad-tech firms simply give up and treat well-defended users as "unknown" — which is the real win.

FAQ

Related reading: The Real Cost of the "Free" Internet · Ad-Tech Glossary · vs PageSpeed Insights