First-party vs third-party cookies and consent
First-party cookies belong to the site you visit, third-party ones to other domains. Why that doesn't decide consent, what browsers block, what to check.
A first-party cookie is set for the site in the address bar. A third-party cookie is set for a different domain, usually by a script, pixel or iframe that site loads from somewhere else. The difference matters a great deal to browsers, which increasingly block third-party cookies, and much less to the law. Whether a cookie needs consent depends on what it is used for, not on whose domain it sits on.
The difference, and the catch
On shop.example, a cookie for shop.example is first-party. A cookie for an ad network's
domain, set when the shop's page loads that network's pixel, is third-party: the browser
stores it under the ad network's domain, and it can recognise the same browser on every other
site that loads the same pixel. That is what made third-party cookies the backbone of
cross-site tracking.
The catch is that a first-party cookie is not necessarily yours. Google Analytics writes its
_ga cookie on your own domain, and the Meta Pixel writes _fbp on your domain too. To the
browser both are first-party. The data goes to Google and Meta.
Regulators noticed this early. The Article 29 Working Party's 2012 opinion on the cookie exemption describes two meanings of "third party": a cookie set by a different organisation, and a cookie set by a different domain. "While these two approaches often overlap, they are not always equivalent." Spain's AEPD goes further in its cookie guide: a cookie served from the publisher's own domain cannot be treated as first-party if a third party uses the data it collects for its own purposes.
| Cookie | What the browser sees | Who uses the data | Consent in the EU |
|---|---|---|---|
| Login session | First-party | You | Not needed: strictly necessary |
_ga (Google Analytics) | First-party | You, through Google | Needed, apart from narrow national exemptions |
_fbp (Meta Pixel) | First-party | Meta, for advertising | Needed |
| An ad network's cookie on its own domain | Third-party | The ad network | Needed |
| A social network's cookie when a logged-in member uses its share button | Third-party | The social network | Can be exempt, for that sharing function only |
The last row is the Article 29 WP's own example of a third-party cookie that can be exempt, provided it is used only to deliver the sharing feature to members who are logged in.
Why the label does not decide consent
The EU rule, Article 5(3) of the ePrivacy Directive, turns on necessity: is the storage strictly necessary for a service the visitor explicitly requested, or used solely to transmit a communication? It does not mention first or third parties.
The Article 29 WP treats the label as a hint at most. First-party session cookies "are far more likely to be exempted from consent than third party persistent cookies", it says, but "the purpose of the cookie should always be the basis for evaluating if the exemption can be successfully applied rather than a technical feature of the cookie". Third-party cookies are usually not strictly necessary because they serve someone else's service, not the one the visitor came for. That is a finding about purpose, not about domains.
You are also answerable for third-party cookies on your site. The CNIL's guidelines say an organisation that allows trackers on its site, including third parties' trackers, must make sure a consent mechanism is actually in place. They also treat the site and the third party as joint controllers where they decide together why and how those trackers are used.
Moving tracking into first-party cookies or server-side setups does not escape the rule either. The EDPB's guidelines on the technical scope of Article 5(3) were written partly because new tracking methods are replacing cookies as some browsers drop third-party cookie support, and they apply the rule to tracking pixels, tracking links, IP-based tracking and unique identifiers. More on how purpose decides in which cookies need consent.
What browsers block today
| Browser | Third-party cookies | Other limits |
|---|---|---|
| Safari | Blocked by default. WebKit's tracking prevention page: "There are no exceptions to this blocking", apart from access granted through the Storage Access API and a compatibility fix for popups | Cookies created in JavaScript are deleted after 7 days without interaction with the site, or capped at 24 hours when the visitor arrives through a decorated link from a known tracker; cookies set through third-party CNAME cloaking are capped at 7 days |
| Firefox | Known tracking cookies blocked by default since 2019. Since June 2022, Total Cookie Protection keeps each site's cookies in a separate jar for all desktop users | |
| Chrome | Left to the user. In April 2025 Google said it would keep offering the choice in Chrome's settings, with no new standalone prompt; Incognito blocks them by default | In October 2025 Google retired most Privacy Sandbox technologies, including Topics and Protected Audience, and kept CHIPS, FedCM and Private State Tokens |
Two things follow. Third-party cookies now work unevenly: for Safari and Firefox visitors, cross-site tracking through them is already largely blocked, while Chrome has not phased them out. And a browser blocking a cookie is not the same as a site asking for consent. The law applies to whatever your site does run, in every browser.
What to check on your site
- List every cookie with its domain and its purpose. Run our cookie checker on a page, or scan the whole site.
- Find the first-party cookies other companies write.
_ga,_fbpand their cousins look like yours in DevTools. Classify them by who uses the data. - Watch requests, not only cookies. A pixel can send data without setting a cookie you would notice. The Apoteket case in our look at what regulators punish turned on what a pixel sent, not on the cookies it set.
- Gate server-side and CNAME setups too. Moving a tag to your own subdomain changes what the browser sees, not what the law asks.
- Check the signals you send Google. If you use Google tags, the Consent Mode checker shows what they receive before and after a choice.
Info
Browser rules change more often than the law. Safari and Firefox have tightened their defaults since 2019, and Chrome has changed its plans more than once. Build your consent setup on what each cookie is for, which is what the law looks at.
Where Katla fits
Katla's scans record first-party and third-party cookies alike, with the domain, expiry and
flags of each and the page it appeared on, plus the tracking requests pages make. Each cookie
is then classified with AI by purpose and provider, so a _ga on your domain
is filed as analytics from Google rather than as one of your own cookies.
On the page, the cookie guard works on cookies written by scripts in the page: in GDPR mode
it blocks non-functional ones before consent and deletes any set earlier. A true third-party
cookie arrives in a response from another domain, so the way to stop it is to hold back the
script that makes the request: scripts tagged with data-katla-category wait until their
category is accepted.
This post describes how cookies and browsers work and summarises regulator guidance. It is not legal advice.