Conversion Tracking & Data

First-Party Cookies vs Third-Party Cookies: What Still Works for Tracking

In short: Both are small pieces of data a browser stores to help a site or script recognize a visitor again. The split is who set it: a first-party cookie is written by the domain the visitor is actually on, while a third-party cookie is written by an embedded ad-tech domain riding along on someone else's site. Safari and Firefox block third-party cookies outright, and Chrome kept them alive after walking back its 2025 phase-out plan, so third-party cookies now work inconsistently depending on which browser your traffic uses. First-party cookies still function everywhere, subject to Safari's own lifespan limits on script-set ones. Rule of thumb: if it needs to survive Safari or Firefox, it has to be a first-party cookie; anything still leaning on third-party cookies is already broken for a meaningful share of traffic.

By the AdFlint research team · Fact-checked against current Google and Meta platform behavior · Last reviewed July 2026

First-Party Cookies

Set by the domain a visitor is actually on, readable only by that site, and used for sessions, carts, and measurement.

The browser stores them against your own domain, so they survive the third-party blocking that Safari and Firefox apply by default. Advertisers depend on them for session continuity and for holding click identifiers like the gclid. The limit people miss is lifespan: Safari's tracking prevention caps cookies written by JavaScript at seven days or less, which is why server-set cookies and server-side tagging exist.

Full definition

Third-Party Cookies

Written by a domain other than the one being visited, historically the backbone of cross-site retargeting and frequency capping.

An embedded script from an ad network writes a cookie under its own domain, letting it recognize the same browser across unrelated sites. Safari and Firefox have blocked them by default for years. Chrome's phase-out was repeatedly delayed and then abandoned in 2025, so they still function there, but building new measurement on them is a mistake, since the practical coverage they offer has already collapsed.

Full definition

Side by side.

The differences that actually change what happens in your account.

 First-Party CookiesThird-Party Cookies
Who can read itOnly the domain that set it - your own site.The ad-tech domain that set it, across every site where its script is embedded.
Default treatment in Safari and FirefoxAllowed - these are the cookies session and cart logic depend on.Blocked outright by default, with no exceptions for advertisers.
Status in ChromeUnaffected - was never targeted for blocking.Still functions after Chrome abandoned its phase-out plan in 2025, but that's one browser, not the whole picture.
Typical lifespanCapped for JS-set cookies by Safari's ITP at about a week; server-set first-party cookies can last much longer.No lifespan cap where allowed, but blocked before lifespan is ever relevant on Safari and Firefox.
What breaks first when it failsSession continuity, cart state, or a stored click ID for a single visitor.Cross-site recognition and frequency capping for an entire audience pool.
Where it's set fromYour own server or the site's own JavaScript.An ad network's or vendor's script embedded on your page.
Fix when it's unreliableMove critical cookies to server-side setting on your own domain to outlast ITP caps.There isn't a fix - replace the dependency with first-party signals like server-side conversions or Customer Match.

What actually separates them.

01

A first-party cookie is scoped to the domain that set it and only travels with requests back to that domain, while a third-party cookie is scoped to the ad network's domain even though it was written while the visitor was on someone else's site, which is exactly the pattern browsers target for blocking.

02

Safari's ITP caps script-set first-party cookies at about a week without erasing them outright, and a server-set first-party cookie can outlast that cap entirely; third-party cookies get blocked before lifespan is ever a factor on Safari and Firefox.

03

Losing a first-party cookie mid-session breaks continuity for one visitor, like a cart resetting; losing third-party cookies breaks cross-site recognition for an entire audience pool, which shows up as a shrinking retargeting list rather than a single broken session.

04

Chrome kept third-party cookies working after abandoning its 2025 phase-out plan, but that only covers Chrome traffic; any measurement built on third-party cookies still undercounts Safari and Firefox visitors who were never allowed to have them.

05

Click identifiers like gclid or fbclid arrive in the URL and get stored via a first-party cookie or local storage on your own domain, so they were never dependent on third-party cookies working, which is why click-based attribution keeps functioning even as third-party blocking spreads.

Which one should you use?

Use First-Party Cookies when

  • You need a shopping cart or logged-in session to persist across pages during one visit.
  • You're capturing a gclid or fbclid from the landing page URL so a later conversion can be attributed back to the click.
  • You're setting up server-side tagging on a first-party subdomain specifically to survive Safari's ITP lifespan cap.
  • You need a consent or preference flag to persist for a returning anonymous visitor on your own site.

Use Third-Party Cookies when

  • You're troubleshooting why a pixel-based retargeting audience keeps shrinking even though nothing changed in the account.
  • You're auditing an old tag setup and finding dependencies on cross-site cookie matching that need migrating to server-side tracking.
  • You're explaining to a client why frequency capping across multiple sites is unreliable today.
  • You're evaluating whether a vendor's cross-site audience product still works given current browser defaults.

Common questions.

Does Chrome still block third-party cookies in 2026?

No. Chrome abandoned its third-party cookie phase-out plan in 2025, so they still function there by default. Safari and Firefox have blocked them for years regardless, so any measurement built on third-party cookies still misses a meaningful share of traffic no matter what Chrome does.

Why did my retargeting audience shrink even though I didn't change targeting?

Third-party cookies are blocked by default on Safari and Firefox, so any audience built from cross-site cookie matching only ever grows from Chrome traffic and a shrinking slice of other browsers. The drop usually isn't an account change - it's the underlying mechanism losing coverage.

Can I turn a third-party cookie into a first-party one?

Not directly, but you can replicate the functionality: set the equivalent cookie from your own server or a first-party subdomain instead of relying on an embedded third-party script. That's the core idea behind server-side tagging.

Why does my Safari conversion tracking undercount after about a week?

Safari's ITP caps cookies written by JavaScript at roughly seven days, so any attribution window longer than that silently loses the connection unless the cookie was set server-side instead. Extending the window usually means moving cookie-setting off client-side JS.

Or stop choosing between them.

AdFlint picks the setting, writes the ads, and keeps optimizing inside the Google and Meta accounts you already own.

Related comparisons

All comparisons