Prepare for phasing out third-party cookies
Learn how to audit your code to look for third-party cookies and what action you can take to ensure you're all set for the end of third-party cookies.
Third-party cookies are the main mechanism that enables cross-site tracking and several major browsers either already placed restrictions on third-party cookies in some way or are planning to. Third-party cookies also enable many valid use cases such as managing state in embedded content or enabling user sessions across multiple sites.
As part of the Privacy Sandbox project, Chrome is phasing out support for third-party cookies and proposing new functionality for cookies along with purpose-built APIs to continue supporting legitimate use cases while preserving user privacy. The phase out will be gradual, starting from midway through 2024.
- Identify first-party and third-party cookies in your code. Cookies that contain
SameSite=Nonewill require updates.
- If you use third-party cookies in a fully contained, embedded context, investigate partitioned cookies.
- If you need third-party cookies across multiple sites that form one cohesive group, investigate First-Party Sets.
- If you're not covered by either of these options, investigate other Privacy Sandbox APIs for individual use cases that don't rely on cross-site tracking.
Identify your first-party and third-party cookies
Cookies can be first-party or third-party relative to the user's context; depending on which site the user is on at the time. This distinction between first-party and third-party context on the web isn't always obvious and the effect it has on different resources can vary.
If your cookie is never used on a third-party site, for example if you set a cookie to manage the session on your site and it's never used in a cross-site iframe, that cookie is always used in a first-party context. To identify your first-party or same-site cookies, look for:
- Cookies set without any
- Cookies with
Set-Cookie: cookie-name=value; SameSite=Lax;
Set-Cookie: cookie-name=value; SameSite=Strict;
In this case, your cookie should not be affected by third-party cookie phase out.
If you have not explicitly set the
SameSite attribute with an appropriate value on your first-party cookie, you should do that to ensure consistent behavior across browsers.
There are a number of other sensible defaults for other first-party cookie attributes in the best practice recipe:
For more details, check out Recipes for first-party cookies.
Cookies that are sent in cross-site contexts, like iframes or subresource requests, are generally referred to as third-party cookies. Some use cases for third-party cookies include:
- Embedded content shared from other sites, such as videos, maps, code samples, and social posts.
- Widgets from external services such as payments, calendars, booking, and reservation functionality.
- Widgets such as social buttons or anti-fraud services.
- Remote resources on a page such as
<script>tags, that rely on cookies to be sent with a request (commonly used for tracking pixels and personalizing content).
In 2019, browsers changed the cookie behavior, restricting them to first-party access by default. Any cookies used in cross-site contexts today must be set with
Set-Cookie: cookie-name=value; SameSite=None; Secure
Make sure to review your cookies and have a list of those set with the
SameSite=None. These are the cookies for which you will need to take action to ensure they keep functioning properly.
One way to identify third-party cookies in your code base is to search for cookies containing
Another option is to browse through your site with third-party cookies blocked on your machine and use DevTools to investigate any potential breakage.
To learn more about DevTools features you can use to investigate third-party cookies check out the instructions on chromium.org.
In Chrome version 115 or higher, you can test the browser behavior after third-party cookie phase out by running Chrome from the command line with the flag
--test-third-party-cookie-phaseout. This will block third-party cookies, enable third-party storage partitioning and FedCM, and enable Chrome UI settings for First-Party Sets ("Allow related sites to see your activity in the group").
If your site breaks when third-party cookies are blocked, you can report the issue to Chrome's cookie breakage tracker.
This article was updated on 30 August 2023 to correct a typing mistake in the testing flag
CHIPS (Cookies Having Independent Partitioned State) is a web platform mechanism that enables opting-in to having third-party cookies partitioned by top-level site using a new cookie attribute
If you have a service that is used as a component on another site, any cookies it sets are in a cross-site context. The way cookies currently work, the same cookie that service C sets on site A, can be read when service C is embedded on site B.
If your service and the sites using it have a 1:1 relationship, those cookies are only ever needed on the site where they were set and not used across multiple sites. Examples include saving preferences for a widget or sharing a session cookie for an API.
In this case, having cookies partitioned by top-level site is an improvement as it reduces the complexity and risk of cross-site data leaks. Third-party cookies can still be used across sites, however, you will see different cookies when the browser is on different top-level sites.
Set-Cookie: __Host-cookie=value; SameSite=None; Secure; Path=/; Partitioned;
For more details about technical design, use cases, and testing, check out CHIPS documentation.
First-Party Sets (FPS) is a web platform mechanism for developers to declare relationships among sites, so that browsers can use this information to enable limited cross-site cookie access for specific, user-facing purposes. Chrome will use these declared relationships to decide when to allow or deny a site access to their cookies when in a third-party context.
If a cookie is used across multiple related sites, blocking cross-site cookies or partitioning by top-level site would prevent use cases such as single sign-on or a shared shopping cart.
The sets are declared in JSON format–in the example below, the primary domain is
air-travel.site is in the list of associated sites.
Top-level sites can request storage access on behalf of specific origins with
For more details about technical design, use cases, and set submission process, check out First-Party Sets developer documentation.
Privacy Sandbox APIs replacing the need for cookies
CHIPS and First-Party Sets cover use cases that can continue to rely on cross-site cookies in a privacy-preserving way.
If neither meets your needs, there is a wider set of Privacy Sandbox proposals for new APIs for specific use cases, replacing the need for cookies. Some of the new APIs are focused on identity, fraud detection, and more, while others cover advertising.
Federated Credential Management (FedCM) enables privacy-preserving approach to federated identity services so users can log into sites without sharing their personal information with a third-party service or website.
Private State Tokens convey a limited amount of information from one browsing context to another (for example, across sites) to help combat fraud, without passive tracking.
A suite of APIs is available to cover ad relevance and measurement use cases such as interest-based advertising, on-device auctions for custom audiences, cross-site content selection, ad conversion measurement and attribution, and more.
To learn more about how new APIs might serve use cases that are not covered in this post, explore the Privacy Sandbox documentation.