Only the Domain Decides First-Party vs Third-Party Cookies

What is the difference between first party vs third party cookies?

Browsers sort first-party vs third-party cookies with one test, comparing the domain that set the cookie against the domain in the address bar: the cookie is first-party when the two match, third-party when they do not. Nothing inside the cookie enters that test, not the name, not the value, not the owner. MDN's third-party cookies guide states the rule outright: "If the cookie domain and scheme match the current page the user is looking at (the URL shown in the browser's address bar), the cookie is considered to be from the same site as the page, and is referred to as a first-party cookie." Different domain or scheme, third-party cookie.

Almost every page online describes the split as your cookie against an advertiser's cookie. That framing is wrong. An ad network's cookie, read on the ad network's own site, is first-party; your own login cookie, read inside an iframe on a partner's site, is third-party.

Why is the same cookie sometimes first-party and sometimes third-party?

The category belongs to the read, not to the cookie. A stored cookie carries a domain, and the browser re-runs the comparison on every request, so moving the read to a different top-level site flips the answer.

Take a support widget that sets a cookie on widget.example. A visitor sitting on https://widget.example sends that cookie as a first-party cookie, because the cookie domain matches the address bar. The same visitor opens https://shop.example, where the same widget loads in an iframe. The browser compares widget.example against shop.example, gets no match, and the identical cookie travels as a third-party cookie under every restriction the browser puts on that category. One cookie in storage, two categories, decided per request.

What did Chrome actually do about third-party cookie deprecation?

Chrome cancelled it. Anthony Chavez, VP of Privacy Sandbox, wrote on 22 April 2025 that Google had "made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies." Third-party cookies stay enabled by default in Chrome's normal browsing mode, and the control stays in Privacy and Security settings. Chrome's help documentation states that third-party cookies are blocked by default in Incognito mode, so the block applies to a browsing mode instead of to the browser.

Any article still quoting a phase-out date is quoting a plan Google withdrew. Build against what ships: Safari blocks, Firefox partitions, Chrome allows outside Incognito.

What do Safari and Firefox do to third-party cookies?

Safari deletes the category and Firefox splits it. John Wilander announced full blocking on the WebKit blog on 24 March 2020 in one sentence: "Cookies for cross-site resources are now blocked by default across the board." WebKit's tracking prevention policy confirms that Intelligent Tracking Prevention "blocks all third-party cookies" and leaves one route back, the Storage Access API, which prompts the user first.

Firefox took the other path. Mozilla rolled out Total Cookie Protection to all users worldwide on 14 June 2022, and it keeps third-party cookies alive inside a boundary: "any time a website, or third-party content embedded in a website, deposits a cookie in your browser, that cookie is confined to the cookie jar assigned to only that website." An embedded tracker still gets a cookie on every site it appears on, and gets a different one each time, which kills the cross-site join without killing the widget.

First-party vs third-party cookies compared

The last row explains why blocking landed on one side. Blocking third-party cookies breaks other people's cross-site plumbing; blocking first-party cookies would break the web.

What breaks when third-party cookies are blocked?

Cross-site state breaks, and only cross-site state. Single sign-on through an identity provider in an iframe stops recognising the user, an embedded checkout or chat widget loses the returning customer, and an ad platform loses conversion attribution and frequency capping, because each needs one identifier read on two different top-level sites.

Two replacements cover the parts worth keeping. The Storage Access API lets an embedded frame ask the user for its unpartitioned cookies. Partitioned cookies handle the rest.

How do partitioned cookies change the picture?

Partitioned cookies keep the third-party cookie and remove the cross-site join by adding the top-level site to the storage key. MDN documents the mechanism as CHIPS, Cookies Having Independent Partitioned State, and records it as Baseline newly available since December 2025. The change is one line of key structure:

storage key = (top-level site, cookie domain) instead of storage key = (cookie domain)

Work an example with MDN's own values. A widget on 3rd-party.example sends Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned; while embedded on site-a.example, and the browser stores it under {("https://site-a.example"), ("3rd-party.example")}. On site-b.example the widget asks for the cookie, the browser searches for {("https://site-b.example"), ("3rd-party.example")} and finds nothing. The widget works on both sites and links neither to the other.

Do first-party cookies survive everything?

No, and the exception catches analytics first. WebKit's tracking prevention policy commits ITP to "deleting all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction", which covers a first-party cookie written by an analytics script on your own domain. The rule keys on how the cookie was written, not whose domain it sits on, so the 7-day cap on Safari cookies shortens any client-side identifier.

The visible effect is inflated new-visitor counts, because a returning visitor past the cap arrives with no identifier and starts a new session. Set identifiers from the server in a Set-Cookie response header if you need them to outlive the cap.

What does this mean for measuring your own site?

Analytics that leans on a third-party cookie measures Chrome's normal browsing mode and little else. Moving the identifier to a first-party cookie widens coverage and hits the ITP cap, which is why measurement keeps drifting toward the server: read the case for server-side tracking before rebuilding a client-side identifier for the third time.

Neither category escapes consent law. Article 5(3) of the ePrivacy Directive asks whether information is stored on or read from the device, so a first-party analytics cookie triggers it exactly as a third-party one does, which is what a consent banner exists to satisfy. Storing no identifier removes the trigger, and cookieless analytics covers what that costs you.

Flowsery is built that way. Its privacy-first analytics is cookie-free, EU-hosted and GDPR by design, ships as one script under 10 KB, and applies no data sampling, so it never lands on either side of the first-party and third-party divide.

Frequently asked questions

Is a first-party cookie always safe from browser blocking?

No. Safari's ITP deletes cookies created in JavaScript, along with other script-writable storage, after 7 days without user interaction, and that applies on your own domain. A first-party cookie set by the server in a Set-Cookie response header falls outside that rule. What matters is how the cookie was written, not who owns the domain.

Does the browser look at who owns the domain?

No. The browser compares the cookie's domain and scheme against the top-level page in the address bar and nothing else. Ownership, company, and purpose never enter the comparison, which is why an advertiser's cookie is first-party on the advertiser's own site.

Can one cookie be both first-party and third-party?

Yes, and the same stored cookie switches between the two on every request. Read on the domain that set it, the cookie is first-party. Read from an iframe on a different top-level site, the identical cookie is third-party and inherits every third-party restriction.

Why does a third-party cookie need SameSite=None and Secure?

Cross-site requests carry a cookie only when it is marked SameSite=None, since the browser default is SameSite=Lax. MDN states that "if SameSite=None is set then the Secure attribute must also be set", restricting it to HTTPS. Without both attributes, a modern browser never sends the cookie cross-site.

Did Google ever remove third-party cookies from Chrome?

No. Anthony Chavez wrote on 22 April 2025 that Google would "maintain our current approach to offering users third-party cookie choice in Chrome" and would not roll out a standalone prompt. Chrome allows third-party cookies by default in normal browsing and blocks them by default in Incognito mode, per Chrome's help documentation.

Does Firefox delete third-party cookies like Safari does?

No, Firefox isolates them instead. Total Cookie Protection, default worldwide since 14 June 2022, confines every cookie to "the cookie jar assigned to only that website", so an embedded tracker gets a separate cookie on each site it appears on. The embed keeps working, and the cross-site profile never assembles.

What does CHIPS stand for?

CHIPS stands for Cookies Having Independent Partitioned State, the mechanism MDN documents behind partitioned cookies. It adds the top-level site to the cookie's storage key, so the same cookie domain gets a separate value on every site that embeds it. MDN records CHIPS as Baseline newly available since December 2025.

What is the Storage Access API?

The Storage Access API lets an embedded iframe ask the browser for access to its unpartitioned cookies, with a prompt to the user first. Safari's WebKit tracking prevention policy names it as the one route back after blocking all third-party cookies. Partitioned cookies cover the rest of what cross-site state needs to keep working.

Do first-party cookies need consent too?

Article 5(3) of the ePrivacy Directive asks whether information is stored on or read from the device, not which domain owns it, so a first-party analytics cookie triggers the same consent requirement as a third-party one. A consent banner exists precisely to satisfy that requirement, regardless of the cookie category. Storing no identifier at all removes the trigger entirely.

Why does a returning visitor sometimes count as a new visitor in analytics?

A returning visitor who arrives after Safari's 7-day ITP cap has no identifier left, so analytics starts a new session and counts them as new. The rule applies to any client-side cookie written by JavaScript, including first-party analytics scripts on your own domain. Setting identifiers from the server in a Set-Cookie response header avoids the cap entirely.