The cross-site cookie that powered a decade of ad tech is already blocked in most browsers. Here's what actually replaces it, and why some of the answers are simpler than the ad industry admits.
For roughly two decades, the third-party cookie was the invisible plumbing of the ad-supported web. It let a company you never visited recognise you across thousands of unrelated sites, build a profile, and attribute an eventual purchase back to an ad you saw a week earlier. That mechanism is now mostly gone or going. Safari and Firefox block third-party cookies by default and have for years; Chrome has spent a long time rebuilding the whole model under the "Privacy Sandbox" banner. The end state is still moving, but the direction is settled.
This article covers what third-party cookies actually did, where each major browser really stands (honestly, because the headlines have been misleading), and the concrete things that fill the gap — including the boring, durable ones that most coverage skips.
What a third-party cookie actually did
A cookie is "third-party" when it's set by a domain different from the one in the address bar. Visit news-site.example, and that page loads an ad script from adtech.example. The ad script sets a cookie scoped to adtech.example. Visit an unrelated recipes.example that also loads adtech.example, and the same cookie comes back. Now one company has linked two of your visits across sites it doesn't own.
Stacked across a huge network of publishers, that single trick powered two big jobs:
- Cross-site tracking and profiling. Following a user from site to site to infer interests, demographics, and intent for ad targeting and retargeting (the "you looked at shoes, now shoes follow you" effect).
- Conversion attribution. Proving that an ad impression or click on one site led to a purchase on the advertiser's own site later, so ad spend could be measured and optimised.
Both jobs are legitimate business needs. The problem was the method: silent, cross-site, hard to see or control, and increasingly at odds with privacy law and user expectation.
Where the browsers actually stand
The single most important thing to understand: this is not one future event. Two of the three major engines already did it, and did it a while ago.
- Safari (WebKit) has blocked third-party cookies by default since Intelligent Tracking Prevention (ITP) matured — full third-party cookie blocking has been the default for years. On Apple's platforms, cross-site cookie tracking is effectively already dead.
- Firefox (Gecko) blocks third-party tracking cookies by default through Enhanced Tracking Protection (ETP), and its Total Cookie Protection isolates cookies per site ("jars") so a third-party cookie can't be shared across the sites that load it.
- Chrome (Chromium) is the one still in motion. Google's Privacy Sandbox initiative has been building replacement APIs for years, and the plan for how and when third-party cookies are removed has shifted more than once. Rather than a single hard cutoff, Google's more recent direction has leaned toward user-choice and continued Sandbox development. Because this has changed before, the honest statement is: the direction is away from third-party cookies, but no specific final deprecation date should be treated as settled. Build for a world without them; don't bet your timeline on a particular calendar date.
The practical takeaway for anyone building analytics or advertising: a large and growing share of your audience — everyone on Safari and Firefox already — cannot be tracked with third-party cookies today. If your measurement depends on them, it's already undercounting.
Replacement 1: first-party data and server-side tagging
The most durable replacement isn't an API at all — it's owning the relationship. First-party data is information a site collects directly from its own users on its own domain: accounts, logins, newsletter signups, purchases, on-site behaviour. It's set as a first-party cookie or stored server-side, and no browser is trying to kill that, because it's the site the user actually chose to visit.
Related to this is server-side tagging: instead of loading a dozen third-party marketing scripts directly in the browser, the site sends events to its own server endpoint, and the server forwards what's needed to downstream tools. This gives the site owner control over what data leaves, reduces client-side script bloat, and keeps measurement working when browsers restrict third-party scripts. It is not a loophole to resurrect cross-site tracking — done responsibly, it's consent-gated and scoped to first-party context.
Replacement 2: the Privacy Sandbox APIs
Chrome's Privacy Sandbox is a set of browser APIs meant to deliver the outcomes advertisers wanted (relevance, audiences, measurement) without letting any party silently rebuild a cross-site identity. At a conceptual level, the main pieces are:
- Topics. The browser itself infers a handful of coarse interest categories (like "Travel" or "Fitness") from recent browsing, keeps them on-device, and shares only a few, slowly-rotating topics with sites — instead of a precise cross-site profile assembled by a third party.
- Protected Audience (formerly FLEDGE). Supports remarketing and custom audiences by running the ad auction locally in the browser, so "this user was in an advertiser's audience" doesn't require the advertiser to track the user across the open web.
- Attribution Reporting. Lets advertisers measure that ad clicks or views led to conversions using browser-generated, aggregated and noised reports, rather than joining an individual's impression and purchase via a shared cookie.
The common thread: computation moves into the browser, and what leaves is deliberately coarse, aggregated, or noised so it can't be turned back into a personal cross-site identifier. These APIs are real and shipping in Chrome, but they're Chromium-specific and still evolving — treat them as one option, not a universal standard.
Replacement 3: contextual advertising
The oldest idea on this list is having a strong comeback. Contextual advertising targets the page, not the person: show running-shoe ads on an article about marathon training, because the content is the signal. No profile, no cross-site identity, no cookie required — the targeting data is simply what the page is about.
Contextual is fully privacy-compatible by construction, works identically in every browser, and has grown considerably more sophisticated than the crude keyword matching of the past. It won't replicate every retargeting scenario, but for a large share of advertising, "relevant to what you're reading right now" is both effective and durable.
Replacement 4: first-party campaign URLs (UTM and friends)
Here's the piece that too many teams overlook while chasing exotic APIs: you can track which campaign brought a visitor to your own site without any third-party cookie at all, because the information travels in the URL. This is what UTM parameters do.
When someone clicks a tagged link like https://example.com/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=august-launch, your own analytics — first-party by definition — reads those query parameters on arrival and records where the visit came from. The five standard fields are utm_source, utm_medium, utm_campaign, utm_term, and utm_content. Nothing about this depends on cross-site cookies; it's your site reading a parameter on its own inbound request.
The discipline that makes it work is consistency. If one link says utm_source=newsletter and another says utm_source=Newsletter or utm_source=news-letter, your reports fragment into meaningless near-duplicates. Clean, well-formed, consistently-cased campaign URLs are the whole game.
Tool walkthrough
Building and reading these first-party campaign URLs is exactly where two Toolhub utilities fit. Use the query string builder to assemble a tagged link field by field — set utm_source, utm_medium, and utm_campaign as key/value pairs and get a correctly encoded, consistently formatted URL out the other side, with no hand-typed ?/& mistakes and no casing drift between campaigns.
Going the other direction, when you land on a tagged URL and want to see exactly what parameters it carries — your own or one you're auditing from a partner — the URL parser breaks it into its parts: scheme, host, path, and each individual query parameter decoded and listed. That's the fast way to confirm a campaign link is tagged the way you intended before you send it, and to inspect inbound links that don't match anything in your reports. Both tools run entirely in the browser, so the URLs you're checking never leave your machine.
Where to read further
- MDN: Third-party cookies — a clear, vendor-neutral explanation of how they work and why browsers are restricting them.
- Google's Privacy Sandbox site — the canonical source for the current status and scope of Topics, Protected Audience, and Attribution Reporting.
- Mozilla: Enhanced Tracking Protection — how Firefox blocks third-party tracking cookies by default.
The takeaway is calmer than the panic suggests. Third-party cookies are going, but the jobs they did split cleanly into pieces that already have homes: own your first-party relationship, measure with server-side and Sandbox tooling where it fits, target content instead of people where you can, and tag your own inbound links cleanly so campaign tracking never needed a cross-site cookie in the first place. Start with the last one — it's the easiest, it works in every browser today, and it's entirely within your control.
← All articles