Third party cookies, explained for publishers who sell ads

Third party cookies are small text files set by a website other than the one you're visiting, usually by an ad server, analytics tool or social widget loaded on the page. Because the same company sits on many sites, its cookie can recognise one browser across all of them, which is what makes ad retargeting and frequency capping work.

Here's why that matters to you as a publisher. Every time your page loads, buyers decide how much your ad slot is worth. A big part of that decision is whether they can recognise the visitor. When they can't, many bid less, or skip the impression.

You've probably read that these cookies are going away. That's only half true, and the half that's true already affects your revenue today. This guide covers what they are, how they work on your pages, where every major browser stands in 2027, and what to set up so your ads keep earning either way. If you'd rather have that set up for you, our header bidding service handles the ID and consent side of the auction.

What are third party cookies?

A third-party cookie is a cookie set by a site that's different from the site in the address bar. Google's Privacy Sandbox basics page defines it that way, and MDN's privacy guide on cross-site cookies adds the rule browsers use: if the cookie's domain and scheme don't match the page's site, it's third-party.

So when someone asks "what are third party cookies?", the honest short answer is: cookies that belong to someone other than you, set while your page is open.

The "third party" isn't about who owns the company. It's about the domain. If you run two sites, say a recipe site and a gardening site, a cookie your recipe site sets inside a frame on the gardening site is third-party there, even though you own both. Google's page makes this point, and it catches out publishers with several domains who assume their own cookies are always "first-party".

Where they come from on a typical publisher page

• Ad tech. Ad servers, SSPs, DSPs and data companies whose scripts or pixels load with your ads.
• Analytics and measurement. Some analytics, attribution and verification tags.
• Embeds and widgets. Video players, social share buttons, comment systems and maps.

Open any ad-supported page with your browser's developer tools and you'll usually find cookies from a dozen or more domains. Most of them arrived with the ads.

How do third party cookies work?

They work by riding along with content your page loads from another domain. When that domain's server answers the request, it can set a cookie in the browser. Next time the same browser loads anything from that domain, on any site, the cookie goes back with the request.

Here's what that looks like in a real ad call, step by step:

1. A visitor opens your article. Your page loads its ad tags, for example Google Publisher Tag or a Prebid wrapper.
2. The ad tech domain gets a request. Say an SSP's script loads from its own domain. The browser sends any cookie that SSP set earlier, on any site.
3. The SSP recognises the browser. Its cookie holds a random ID. The SSP has matched that ID with buyers' IDs before, a process called cookie syncing.
4. Buyers bid with more context. A DSP that knows this browser visited a running shoe store last week may bid more for a sports advertiser.
5. The cookie gets updated. The ad tech company notes the visit, so the next site the visitor opens knows a little more.

One technical detail you'll meet in error logs: for a cookie to be sent in a cross-site request, it has to be marked SameSite=None, and MDN notes that such a cookie must also carry the Secure attribute. Without SameSite, Chromium browsers treat the cookie as Lax, which blocks most cross-site use. That's why a vendor tag that sets cookies wrongly can quietly stop working.

What ad tech uses them for

For a publisher, the uses come down to five jobs, all of them done by your ad partners rather than by you:

• Audience targeting. Buyers bid on people who match a segment, such as "in market for a car".
• Retargeting. A store shows its ad to people who visited it, on your page.
• Frequency capping. The same ad doesn't show to one person 30 times.
• Measurement. Advertisers count views and conversions, and verification firms check where ads ran.
• Fraud checks. A browser with a long, normal history looks more human than a brand new one.

One page-one guide says these cookies are "mostly" for analytics. On an ad-supported site that's not what we see. Ad tech sets most of them.

First party vs third party cookies

The difference between first party vs third party cookies is who sets them and where they can be read. Your own site sets first-party cookies, and only your site can read them. Another domain sets the third-party kind, and that domain can read them on every site that loads it.

Notice the first-party cookies row. They aren't free of rules either. A first-party cookie used for ads still needs consent where the ePrivacy rules apply. What changes is that browsers don't block it.

A mistake we often see: a publisher hears "first-party data" and assumes it means they can track visitors freely. It doesn't. It means the data comes from your own relationship with the reader, with their permission.

Are third party cookies going away?

No, not in Chrome. On 17 October 2025 Google said Chrome "will maintain our current approach to offering users third-party cookie choice", in its update on plans for Privacy Sandbox technologies. But Safari and Firefox already block or wall them off by default, so for a large part of your traffic they're gone already.

The question "are third party cookies going away?" has had a lot of wrong answers over the years. Plenty of guides still on page one say Chrome is phasing them out, or quote a 2024 timeline. Here's where things actually stand.

Third party cookies in Chrome

Third party cookies in Chrome stay on by default. MDN puts it plainly: Chrome doesn't block them by default, only in Incognito mode or when a user chooses to block them in settings. Google's October 2025 post also retired most of the Privacy Sandbox ad APIs that were meant to replace cookies, including Topics, Protected Audience, Attribution Reporting and IP Protection. It kept CHIPS, FedCM and Private State Tokens, which deal with cookie privacy, sign-in and fraud rather than ad targeting. We list every retired API and what to remove from your setup in our Privacy Sandbox guide for publishers.

So if a vendor is still pitching you a Topics API or Protected Audience integration, ask what it does now. Those APIs are on Google's retirement list.

Safari and Firefox

Safari blocks cross-site cookies by default and has since March 2020. WebKit's post on full third-party cookie blocking says cookies for cross-site resources "are now blocked by default across the board". Plan as if your Safari visitors on Mac, iPhone and iPad have none at all.

Firefox turned on Total Cookie Protection by default for all desktop users worldwide in June 2022, according to Mozilla's announcement. It gives each site its own separate cookie jar, so a cookie set on your page can't be read on another site. For cross-site tracking, that has the same effect as blocking.

The practical takeaway: "cookieless" isn't a future event. Check your ad reports by browser and you'll likely see it already. It's common for Safari traffic to earn less per impression than Chrome traffic, partly for this reason, though the gap varies a lot by site, country and demand partner.

What third-party cookies mean for your ad revenue

Cross-site cookies raise what some buyers will pay for your slots, because they let them target people instead of pages. When they're missing, those buyers either bid lower, bid only on context, or stay out. You don't lose the impression, but you can lose part of its price.

Not all demand cares equally. Here's how we'd think about it:

• Retargeting and audience campaigns care most. They exist to reach a known browser. No recognisable ID, no bid.
• Brand campaigns bought on context care least. A cooking brand buying cooking pages doesn't need to know who the reader is.
• Frequency caps get weaker. Without a stable ID, buyers can't cap well, so some hold back budget or cap per page view.
• Measurement gets fuzzier. Advertisers who can't measure results on cookieless traffic often value it lower.

Consent matters as much as the browser. If a visitor in the UK or EU declines ads cookies, Google serves non-personalized ads. Google's help page on personalized and non-personalized ads says those ads use contextual information, coarse location such as city, and the content of the current page. It adds that they still use cookies or mobile ad IDs for frequency capping and aggregated reporting. So a "no" on your consent banner turns a Chrome visitor into a partly cookieless one, in ad terms.

That's why we'd rather you look at revenue by browser and by consent status than worry about Chrome news. Those two splits show how much of your traffic already runs without cookie-based targeting. For the metric behind those splits, our guide to CPM and RPM explains what each number measures.

Cookieless advertising, what publishers can do instead

Cookieless advertising means selling ads without relying on third-party cookies to identify the visitor. For a publisher, that rests on four things you control: consent done properly, first-party identifiers, strong page context and a clean supply chain. None of them needs Chrome to change anything.

1. Get consent right

In the UK and EU, ads cookies need consent. Google's page on ads personalization settings in publisher ad tags says consent is required to use cookies for frequency capping and reporting from users where the ePrivacy Directive's cookie rules apply, even for non-personalized ads. A consent banner that loads ad tags before the visitor answers is the most common setup problem we find. Fix that first, because it's a compliance risk as well as a revenue one.

2. Use first-party identifiers

If readers log in or subscribe, you can pass a first-party ID with your ad requests. In Google Ad Manager 360 that's the publisher provided identifier (PPID). Google's PPID help page says it must be 22 to 150 characters and hashed or encrypted so it's meaningless to Google. It isn't available on the free Ad Manager tier. For Prebid bidders, a shared ID such as SharedID or UID2 does the same job; our guide to universal IDs for publishers shows how to set one up.

With header bidding, Prebid's User ID module passes pseudonymous IDs to bidders. Prebid calls these IDs "an important way of increasing the value of header bidding". Pick ID providers your main bidders actually read, and only load them after consent. Step 3 of our five-step cookie deprecation strategy shows a minimal config and how to test whether an ID pays.

3. Make your pages easy to read for context

Contextual targeting uses the page, not the person (our contextual advertising guide for publishers shows the signals to send). Clear categories, descriptive titles and one topic per page all help buyers' systems classify you. The industry's shared list of content categories is IAB Tech Lab's Content Taxonomy, now at version 3.1, which its page says is typically used for contextual targeting and brand safety. A data platform can also turn your own reader data into segments; our DMP guide for publishers covers when that's worth it.

4. Keep the supply chain clean

When buyers can't lean on cookies, they lean harder on trust signals. A correct ads.txt, viewable slots and fast pages make your cookieless traffic easier to buy. It's also why some budgets move to closed platforms with their own logged-in users, which we cover in our guide to walled garden advertising.

What we check first on a publisher's site

When we review a publisher's ad setup for cookie readiness, we work through the same short list in the same order. You can run it yourself in an afternoon.

1. List the cookies. In Chrome, open DevTools, go to Application, then Cookies, and look at the domain column. Every domain that isn't yours is a third party. Do it once before accepting the consent banner and once after.
2. Check what fires before consent. If ad or tracking cookies appear before a UK or EU visitor answers, the banner isn't wired to your tags.
3. Split revenue by browser. In your ad server or analytics, compare RPM for Chrome, Safari and Firefox. The gap is roughly what cross-site tracking is worth to you today.
4. Split revenue by consent. Compare consented and declined traffic in the UK and EU, if your tools allow it.
5. Review your ID modules. In Prebid, check which ID modules load and which bidders read them. Remove ones nobody uses; they add weight for nothing.
6. Check page context. Make sure every article has a clear category and the page title says what it's about.
7. Fix vendor cookie errors. In DevTools, look for cookies blocked for a missing SameSite=None; Secure pair and send them to the vendor.

Most sites we look at have at least one of the first two wrong. Neither is hard to fix, and both matter more than any Chrome announcement.

Frequently asked questions

What are third party cookies in simple terms?

They're cookies saved by a website other than the one you're on, usually by an ad or tracking company whose code is on the page. Because that company is on many sites, its cookie can recognise the same browser across all of them.

Are third party cookies going away in Chrome?

No. In October 2025 Google said Chrome will keep its current approach of letting users choose, and it retired most of the Privacy Sandbox ad APIs. Safari and Firefox still block or partition them by default.

What is the difference between first-party and third-party cookies?

First-party cookies are set by the site you're visiting and can only be read there. Third-party ones are set by another domain loaded on the page and can be read on every site that loads that domain, which is what allows cross-site tracking.

Do I need consent for ad cookies on my site?

In the UK and EU, yes, for advertising and tracking uses. Google's ad tags also need consent there to use cookies for frequency capping and reporting. Rules elsewhere vary, so check the laws for the countries your visitors come from.

Can I still earn from ads without third-party cookies?

Yes. Ads still serve to Safari, Firefox and declined visitors, using page context, coarse location and first-party IDs. The price per impression is often lower, so the work is in consent, first-party IDs, page context and clean ads.txt.

Should I block these cookies on my own website?

Not across the board if you earn from ads, because your ad partners rely on them where consent allows. Do block or delay them until a visitor gives consent where the law requires it, and remove tags you no longer use.

Next step

Third party cookies still work in Chrome, but a large part of your traffic already sells without them. Set up consent, first-party IDs and good page context, and your ads will earn well whichever browser a reader uses. If you'd like a second pair of eyes on your setup, ask us for a free site review.