A third-party cookie is a cookie set and read by a domain other than the site shown in the address bar, typically through an embedded script, image, frame or advertising tag. Because the same third party can be embedded on thousands of unrelated sites, its cookie can recognize one browser across many websites, which makes it the classic tool of cross-site tracking.
In the context of cookies and consent, the third-party cookie is the category that privacy law and browser vendors scrutinize most closely. Technically it is an ordinary HTTP cookie; what makes it third-party is the relationship between the cookie’s domain and the top-level site at the moment it is used.
How a third-party cookie is set and read
A third-party cookie appears when a page loads a resource from another site and that site’s server responds with a Set-Cookie header, or when a script running inside a cross-site frame writes to document.cookie. On every later request to the same third-party domain, from any website that embeds it, the browser sends the cookie back automatically.
- A user visits a news site that embeds an advertising tag from an ad server.
- The browser requests the tag, and the ad server sets a cookie with a unique identifier on its own domain.
- The user later visits an unrelated shop that embeds the same ad server.
- The browser sends the stored identifier, so the ad server can link both visits to one browser profile.
For this to work in current browsers, the cookie must be marked SameSite=None together with the Secure attribute. Since 2020, major browsers treat cookies without a SameSite value as Lax by default, which blocks them in most cross-site subrequests. Classification is always per request: the same cookie is first-party on its owner’s site and third-party when its domain is embedded elsewhere.
Third-party cookies compared with related techniques
The key difference between cookie types is which site context controls them and how far their reach extends. The table compares the third-party cookie with its closest neighbors in the Topic and with techniques that are often used to replace it.
| Mechanism | Set by | Cross-site reach | Typical purpose |
|---|---|---|---|
| Third-party cookie | Embedded external domain | High across all embedding sites | Ad targeting, retargeting, analytics |
| First-party cookie | The visited site itself | Limited to that site | Sessions, preferences, site analytics |
| Partitioned cookie | Embedded domain, keyed to the top site | None between top-level sites | Embedded chat, maps, payment widgets |
| CNAME-cloaked cookie | Third party behind a first-party subdomain | Depends on data sharing | Evading third-party cookie blocking |
| Device fingerprint | Script computing device attributes | Potentially high, no storage needed | Tracking without cookies |
A partitioned cookie, defined in the CHIPS proposal through the Partitioned attribute, keeps the third-party function of an embed but stores a separate cookie jar for each top-level site, so it cannot follow the user from one site to another. CNAME cloaking and fingerprinting are generally treated by regulators as equivalent to tracking cookies, so they do not escape consent requirements.
Browser restrictions on third-party cookies
Browser vendors have progressively restricted third-party cookies, although they have not all taken the same path. The table summarizes the main approaches without implying that any of them is final, since defaults continue to evolve.
| Browser | Default approach | Mechanism |
|---|---|---|
| Safari | Blocks third-party cookies by default | Intelligent Tracking Prevention |
| Firefox | Isolates them per site by default | Total Cookie Protection, state partitioning |
| Chrome | Still allows them for most users | User controls, SameSite rules, Privacy Sandbox APIs |
| Edge | Blocks known trackers in balanced mode | Tracking prevention lists |
Legitimate embedded services that need cross-site state, such as single sign-on or embedded comments, can request access through the Storage Access API, which typically requires a user gesture and sometimes a prompt. For marketers, the practical consequence is that match rates and attribution windows shrink whenever third-party cookies are blocked, which has driven investment in first-party data and server-side measurement.
Consent requirements and responsibility
In the European Union, setting or reading a third-party cookie that is not strictly necessary requires prior informed consent under Article 5(3) of the ePrivacy Directive, implemented in national law. When the cookie carries an identifier linked to a person’s browsing, the GDPR also applies to the resulting personal data.
The website that embeds the third-party code is not a bystander. The Court of Justice has held that a site operator embedding a social plugin can be a joint controller with the plugin provider for the collection and transmission of visitor data. Site owners therefore carry responsibility for blocking third-party tags until consent is given, usually through a consent management platform.
| Use | Strictly necessary | Consent normally required |
|---|---|---|
| Behavioral advertising and retargeting | No | Yes |
| Cross-site analytics | No | Yes |
| Social media embeds that track | No | Yes |
| Fraud detection on payment widgets | Often yes | Depends on scope |
| Load balancing of an embedded service | Often yes | Usually no |
Consent must be as easy to refuse as to accept, and refusal must actually prevent the cookie from being set. A banner that informs users while tags fire before any choice is one of the most common violations found in audits.
Common pitfalls with third-party cookies
Problems with third-party cookies usually arise from incomplete inventories and from tags that load other tags. A single advertising script can call several further domains, a pattern known as piggybacking, each of which may set its own cookies.
- Unscanned tag chains: only the first vendor is listed in the cookie notice, while downstream partners remain undisclosed.
- Cookie syncing: vendors exchange identifiers through redirects, so one consent may be stretched across many parties.
- Missing attributes: cookies without
SameSite=None; Securesilently stop working in cross-site contexts. - Assuming blocking solves compliance: browser restrictions vary, so legal duties remain whatever the browser does.
- Outdated retention: identifiers that live for years exceed what most audits accept for advertising cookies.
In everyday language
A third-party cookie is a small note left in a browser by another company’s server. It appears while someone visits a different website. That company may have its code on many sites. It can then read its note on each of them and recognize the same browser as it moves around the web.
Picture a shop assistant who also works in many other shops and remembers every customer. That is the idea. For this reason, most third-party cookies require permission before they are set. Several browsers now block or isolate them automatically.
Seen in the real world
A travel booking site embeds a video player, a social sharing button and two advertising tags. A cookie audit shows that, before any consent choice, fourteen third-party domains set cookies on the first page view, several of them through tags loaded by the advertising scripts rather than by the site itself.
The privacy team configures the consent management platform to block all non-essential tags until consent, replaces the video player with a privacy-enhanced embed that sets no cookies before playback, and keeps only a payment provider’s fraud cookie as strictly necessary. After the change, a first page view sets no third-party advertising cookies for visitors who refuse, and the cookie notice lists every remaining vendor accurately.