---
source_url: "https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Third-party_cookies?utm_source=openai"
title: "Third-party cookies - Privacy on the web | MDN"
mirrored_at: 2026-08-04T12:31:54.033Z
host: developer.mozilla.org
cited_in_42a: true
mirror_canonical: "https://index.42a.ai/developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Third-party_cookies__q__utm_source_openai"
---

> **Original source:** https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Third-party_cookies?utm_source=openai

## [What are third-party cookies?](#what_are_third-party_cookies)

A [cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies) is associated with a particular domain and scheme (usually `https`), and may also be associated with subdomains if the [`Set-Cookie`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie) `Domain` attribute is set.

-   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_.
-   If the domain and scheme are different, the cookie is not considered to be from the same site, and is referred to as a _third-party cookie_.

**Note:** Third-party cookies are sometimes referred to as _cross-site cookies_. This is arguably a more accurate name, as _third-party cookies_ imply ownership by a third-party company or organization. However, the behavior and potential issues are the same whether or not you own all the involved sites. For example, a site might access resources such as images from a different domain that they own.

A first-party cookie may be set when a user first visits a page, follows an internal link to another page on the same site, or requests a resource residing on the same site (for example, an embedded image, web font, or JavaScript file).

Third-party cookies are sent in the following common situations:

-   When a link is clicked on one site to navigate to another site.
-   When a page embeds components from other sites, such as images or other documents embedded in [`<iframe>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe)s (often referred to as _third-party content_). As well as the original request for the component, these components may generate further requests that set more third-party cookies.

## [What are third-party cookies used for?](#what_are_third-party_cookies_used_for)

Third-party cookies set when clicking on links to other sites are used for a variety of purposes. For example, you might have an affiliate link to a partner site and set a cookie when the user follows the link so that a reward banner can be displayed with a discount if a certain product is purchased or a commission can be paid back to the referrer.

Third-party content that sets cookies also has many different uses. For example, you might have a sign-in widget embedded on multiple different-but-related sites, which shares a cookie across all sites confirming that the user is signed in, so they don't have to sign in again on each site.

Other use cases for third-party cookies include:

-   Sharing user preference or theme information across multiple sites.
-   Collecting analytics across multiple sites.
-   Counting ad impressions and recording user interests to enable ad-tech platforms to serve more relevant ads.

Let's further illustrate the sign-in widget example mentioned above with a fictional company, which has separate domains for its online shop (`shop.site`), community discussion forums (`forum.site`), and customer service and returns (`service.site`).

Each of the three sites has an embedded sign-in widget, hosted at `auth.site`, to persist sign-in status across sites. A user can sign in to any of those sites, creating a cookie set on the browser for `auth.site` containing a session ID. When the user goes to one of the other sites, the embedded `auth.site` instance will have access to the session ID cookie set when the user signs in on the first site. It can send that to the server, check it is still valid, and sign in to that site immediately.

![visual representation of the above third-party sign-in system description](https://mdn.github.io/shared-assets/images/diagrams/http/cookies/3pc-example.png)

## [What is the problem with third-party cookies?](#what_is_the_problem_with_third-party_cookies)

The above use cases sound innocent enough. However, third-party cookies can also be used for illegitimate purposes without the user's consent, which are technically undistinguishable from valid use cases.

Following a link to a third-party or interacting with third-party content embedded in an `<iframe>` (for example, filling out a form or clicking a button) could result in cookies being set that put a user's information in the hands of someone they didn't expect. This information could be used to:

-   Chase users around the web with targeted ads whenever they search for information on a specific product.
-   Target users with spam emails or phone calls.
-   Manipulate their behavior to choose certain options that increase affiliate revenue or manipulate statistics.

Individually, such cases are bad enough, but it gets worse. Third-party servers can combine information from multiple third-party cookies set across different sites where the third-party content is embedded to create a detailed profile of a user's browsing history, interests, habits, and personal information. This can be used to create creepy, invasive user experiences, defraud users, or even commit identity theft.

In such cases, third-party cookies are referred to as _tracking cookies_.

**Note:** User information gained through illegitimate means is also often sold to other third parties, multiplying the problem further.

Legislation such as the [General Data Privacy Regulation](https://gdpr.eu/ "External link (opens in new tab)") (GDPR) in the European Union and the [California Consumer Privacy Act](https://www.oag.ca.gov/privacy/ccpa "External link (opens in new tab)") (CCPA) have helped by making it a legal requirement for companies to be transparent about the cookies they set and the information they collect. Examples include asking customers to opt into such data collection, allowing them to see what data a company holds on them, and delete the data if they wish. However, it is still not always clear to customers how their data is used.

## [How do browsers handle third-party cookies?](#how_do_browsers_handle_third-party_cookies)

Browser vendors know that users don't like the behavior described above. To mitigate the negative effects on user experience, some have started to block third-party cookies by default, and alternative mechanisms have been implemented for developing legitimate third-party cookie use cases (see [Transitioning from third-party cookies](#transitioning_from_third-party_cookies)).

The following list describes the state of third-party cookie blocking across a selection of browsers:

-   Firefox enables [Total Cookie Protection](https://blog.mozilla.org/en/mozilla/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/ "External link (opens in new tab)") if [Enhanced Tracking Protection](https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop "External link (opens in new tab)") is enabled, as it is by default. This gives third-party cookies a separate cookie jar per site, preventing cross-site tracking.
-   Safari has a [Tracking prevention policy](https://webkit.org/tracking-prevention-policy/ "External link (opens in new tab)") resulting in a similar set of third-party cookie protections that are enabled by default; see [Intelligent Tracking Prevention](https://webkit.org/tracking-prevention/#intelligent-tracking-prevention-itp "External link (opens in new tab)") (ITP) for details.
-   Google Chrome doesn't block third-party cookies by default, only in Incognito mode, or when users explicitly set it to block third-party cookies via `chrome://settings`.
-   Edge blocks trackers from unvisited sites, and blocks known harmful trackers by default. See [Tracking prevention](https://learn.microsoft.com/en-us/microsoft-edge/web-platform/tracking-prevention "External link (opens in new tab)") for more information.
-   The [Brave browser](https://brave.com/ "External link (opens in new tab)") blocks tracking cookies by default.

It is possible to allow usage of third-party cookies on a case-by-case basis in Firefox, Chrome, and Edge via browser settings. In Safari however, control is more limited — you can turn off cross-site tracking prevention, but allowing access to third-party cookies per frame can only be done at the code level, via the [Storage Access API](https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API).

**Note:** Third-party cookies (or just tracking cookies) may also be blocked by browser extensions.

Cookie blocking can cause website functionality and third-party components (such as social media widgets) not to function as intended. As a result, browsers include exceptions and heuristics in their source code to work around long-standing third-party cookie issues with popular websites.

In general, developers should start to look at ways to limit the circumstances in which third-party cookies are sent to reduce their potential for privacy harm, and reduce reliance on them.

## [Limiting third-party cookies with `SameSite`](#limiting_third-party_cookies_with_samesite)

The [`SameSite`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value) attribute lets servers specify whether/when third-party cookies are sent. If you don't specify `SameSite` in your `Set-Cookie` headers, the default value is used, which is `Lax` in Chromium-based browsers and varies across other browsers. As a result, you are advised to set `SameSite` explicitly to ensure consistent behavior.

You should try to use `Lax` as a reasonable default in your apps where possible. This instructs the browser to not send third-party cookies except when the user navigates to the cookie's origin site from a different site. This is useful when you want to send cookies straight away as soon as a user navigates to your site from another site, for example to personalize the experience as soon as they get there.

However, this is no good if you want to embed cross-site content across multiple sites inside `<iframe>`s and rely on third-party cookies for functionality, for example in the case of the sign-in example we looked at above. In such cases, you need to explicitly set `SameSite=None` to allow the browser to pass those cookies around:

http

```
Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly
```

Note that if `SameSite=None` is set then the `Secure` attribute must also be set — `SameSite=None` requires a _secure context_. In the above example we have also set the `HttpOnly` attribute, to disable JavaScript access to the cookie (e.g., via [`Document.cookie`](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie)). Cookies that persist sensitive information should always have the `HttpOnly` attribute set — it would be really insecure to make them available to JavaScript. This precaution helps mitigate cross-site scripting ([XSS](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS)) attacks.

**Note:** Cookies that are used for sensitive information should also have a short [lifetime](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies#removal_defining_the_lifetime_of_a_cookie).

**Note:** You can set a `SameSite` attribute value of `Strict` on cookies if you only want them sent with requests originating from the same site that set the cookie. This effectively blocks third-party cookies from being sent in any circumstances.

## [Transitioning from third-party cookies](#transitioning_from_third-party_cookies)

There are multiple strategies to help sites minimize breakage in browsers where third-party cookies are blocked:

1.  Audit your third-party cookie usage. Cookies must have the `SameSite=None` attribute set to be used in a cross-site context. You can therefore identify third-party cookies by searching for `SameSite=None` in your code, or checking for stored `SameSite=None` cookies in your browser DevTools, for example in the [Firefox Storage Inspector](https://firefox-source-docs.mozilla.org/devtools-user/storage_inspector/ "External link (opens in new tab)"). Chrome's [Issues panel](https://developer.chrome.com/docs/devtools/issues/ "External link (opens in new tab)") also [reports issues with third-party cookie blocking](https://privacysandbox.google.com/cookies/prepare/audit-cookies#chrome-dev-tools "External link (opens in new tab)") along with a list of affected cookies.
2.  Test your functionality with third-party cookies blocked, to see what breaks. You might find that some cookies are no longer needed.
3.  Initially, at least, you could make your code more resilient so that it provides a less personalized experience when third-party cookie data is not available rather than breaking it altogether. Follow the principles of [graceful degradation](https://developer.mozilla.org/en-US/docs/Glossary/Graceful_degradation).
4.  Gather data via alternative means such as user surveys or quizzes, or look at data you already have to infer trends (for example, product order histories).
5.  Use an alternative client-side storage mechanism such as [Web Storage](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API) to persist data, or consider a server-side solution.
6.  If your third-party cookies are only used across a small number of related, known websites, you could use the [Storage Access API](https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API) to allow cross-site cookie access only for those specific sites. Storage Access prompts the user to provide permission for a site to use third-party cookies on a per-frame basis.
7.  If your third-party cookies are being used on a 1:1 basis with the top-level sites they are generated on, you could use [Cookies Having Independent Partitioned State](https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Third-party_cookies/Partitioned_cookies) (CHIPS, aka opt-in partitioned cookies) to opt your cookies into partitioned storage with a separate cookie jar per top-level site. This only requires adding the `partitioned` attribute to your existing cross-site cookies. They can then be used unrestrictedly, but they can't be shared with other sites.

## [See also](#see_also)

-   [HTTP cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies)
-   [Privacy on the web](https://developer.mozilla.org/en-US/docs/Web/Privacy)