Multiple features can affect whether or not third-party cookies are allowed or blocked for an individual Chrome client on a particular website:
- User settings
- Chrome flags
- Grace period
- Chrome-facilitated testing
- Heuristics-based exceptions
- Chrome Enterprise policies
This article shows how these Chrome features interact, and describes tools and techniques to help you understand why third-party cookies are available or blocked.
What causes third-party cookies to be allowed or blocked?
This section explains how third-party cookies may be allowed or blocked for all sites, for an individual site, or for an individual user.
User settings
From chrome://settings, or from the eye icon in Chrome's address bar,
users can set or change the default third-party cookie behavior for their
browser, including blocking all third-party cookies. Users can also add
exceptions to allow third-party cookies for specific sites.
Block third-party cookies
chrome://settings/cookies
Third-party cookies can be blocked from Privacy and security > Third-party cookies. Enabling Block all third-party cookies blocks third-party cookies in all contexts—including where third-party cookies might otherwise be available, such as for Related Website Sets or when mitigations (such as heuristics-based exceptions) are in action.
chrome://settings/cookiesHowever, if Block third-party cookies is enabled from chrome://settings/cookies,
it's possible to allow third-party cookies within Related Website Sets by
enabling Allow related sites to see your activity in the group:
chrome://settings/trackingProtection
Users in the 1% of Chrome clients belonging to the Tracking Protection test group
have third-party cookies restricted by default. These users can block all
third-party cookies from chrome://settings/trackingProtection.
This has the same implications as Block third-party cookies from
chrome://settings/cookies.
chrome://settings/trackingProtectionAllow third-party cookies
From chrome://settings, users can add a site to the list of sites allowed access
to third-party cookies.
Additionally, when third-party cookies are blocked or limited, users are shown the eye icon in the address bar (omnibox) on sites that use third-party cookies.
Clicking the eye icon enables the user to temporarily allow third-party cookies for the current site:
The 1% of users in the Tracking Protection group will see the Tracking Protection dialog:
Using the eye icon to allow third-party cookies for a site has the same effect
as adding the site to Sites allowed to use third-party cookies from
chrome://settings, except that a 90-day expiry is set.
After expiry, the temporary exemption for a site can be renewed if necessary from the eye icon, to allow the site to continue to access third-party cookies.
Third-party cookie access for individual sites can also be revoked. This removes the current site from the list of sites allowed to use third-party cookies:
- User settings to block all third-party cookies override Chrome flags, grace period, and heuristics-based exceptions.
- User settings to change the default third-party cookie behavior for their browser are not available if an Enterprise policy for cookies is set.
chrome://settings/content/siteData
This enables a user to allow or block data storage (including cookies) from individual domains, first-party or third-party. (By contrast, allowing third-party cookie access by adding a site to Sites allowed to use third-party cookies from chrome://settings/cookies or chrome://settings/trackingProtection allows all third-party cookies to be set and read on that site, from any domain.)
You should ensure that chrome://settings/content/siteData doesn't interfere with your testing.
Which temporary mitigations and exceptions are blocked?
Tracking Protection restricts third-party cookies by default, but also allows mitigations to temporarily allow third-party cookies, such as heuristics-based exceptions, and the grace period. Blocking all third party cookies from chrome://settings overrides some of these mitigations.
✅ Third-party cookies allowed
✖ Third-party cookies blocked
| Setting | Privacy Sandbox APIs | Temporary mitigations | User settings | ||||
|---|---|---|---|---|---|---|---|
| CHIPS | Storage Access API with Prompts | Related Website Sets | Heuristics-based exceptions | Grace period | Allow third-party cookies for a specific site | ||
Tracking Protection active, "Block all third-party cookies" not enabled from chrome://settings/trackingProtection |
✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
Tracking Protection active, "Block all third-party cookies" enabled from chrome://settings/trackingProtection |
✅ | ✅ | ✖ | ✖ | ✖ | ✅ | |
Tracking Protection not active, "Block third-party cookies" not enabled from chrome://settings/cookies |
✅ | ✅ | Depends on user settings | ✖ | ✖ | ✅ | |
Chrome flags
Several Chrome flags affect whether or not third-party cookies are allowed or blocked for a single user.
- All Chrome flags are overridden by user settings to block third-party cookies. Conversely, you can't set a flag that blocks third-party cookies, and then "re-enable" them from user settings, except by adding a site to the list of sites allowed to use third-party cookies.
- Learn more: Chrome flags for testing different scenarios.
If you regularly use different Chrome channels with command-line flags, you might want to create functions for each channel, and add these to your shell RC file. For example, on macOS:
- Open a terminal.
- Create a function:
cf(){ open -a 'Google Chrome Canary' --args $\*; } - Use the function by calling it with a flag. For example:
cf --enable-features=TrackingProtection3pcd
Grace period
Chrome's third-party cookie grace period provides a way for sites and services experiencing breakage to request additional time to migrate away from third-party cookies to alternative solutions. Eligible grace period participants will be granted continued access to third-party cookies for a limited time.
- Access to third-party cookies due to grace period activation is blocked by user settings to block all third-party cookies and by Chrome flags that block third-party cookies.
- Chrome flags for testing different scenarios explains how to allow or disallow grace period activation.
Essential site exemptions
Certain sites offering critical services are provided with a temporary exemption that allows them to continue to access third-party cookies.
- Access to third-party cookies due to the essential sites exemption is blocked by user settings to block all third-party cookies and by Chrome flags that block third-party cookies.
- Essential sites can refer to the instructions to allow or disallow grace period activation in Chrome flags for testing different scenarios. The essential sites exemption is disabled when grace period activation is disallowed.
Heuristics-based exceptions
During third-party cookie phaseout, Chrome uses heuristics that grant temporary access to third-party cookies for predefined flows in specific scenarios, in order to mitigate breakage. This is a temporary measure, with the expectation that the heuristics will be removed completely in the future as sites migrate to long-term solutions.
Heuristics-based exception scenarios provides more information about specific scenarios where Chrome would automatically grant access to third-party cookies.
The heuristics-based exceptions demo lets you test third-party cookie access with and without heuristics exceptions.
- Heuristics-based exceptions to allow third-party cookies are overridden by user settings and Enterprise policies to block all third-party cookies.
- Chrome flags for testing different scenarios explains how to allow or disallow heuristics-based exceptions.
Chrome-facilitated testing
Chrome-facilitated testing modes allow sites to preview how sites function without third-party cookies. A percentage of Chrome clients are randomly assigned to one of the Mode A or Mode B experiment group arms, and each arm is provided with a label accessible from a request header or navigator.cookieDeprecationLabel.
Inclusion in a Mode A experiment arm does not affect Chrome behavior, including for third party cookies. There are four Mode B experiment arms, randomly assigned to a total of 1% of Chrome clients (0.25% for each of four arms). Cookies are blocked for Chrome clients assigned to any of these experiment arms.
Chrome has also restricted cookies for 20% of Chrome Canary, Dev, and Beta clients.
- Chrome clients can access third-party cookies for sites added to Sites allowed to use third-party cookies, even if the client is assigned to a Mode B experiment arm (all of which block third-party cookies by default).
- Chrome flags for testing different scenarios explains how to allow, disallow, or force a Chrome-facilitated testing experiment arm to be set for the current Chrome client.
Chrome Enterprise policies
Setting the BlockThirdPartyCookies
policy to
Disabled allows cross-site cookies. Setting the policy to Enabled prevents those
pages from setting third-party cookies. Leaving the policy unset allows
third-party cookies by default and enables users to block third-party cookies
from chrome://settings.
You can read more in the Chrome Enterprise help center article.
- Users cannot override Enterprise policies from
chrome://settingsor Chrome flags.
Understand cookie status
This section explains how to check whether third-party cookies are allowed or blocked for a user or site.
chrome://settings
Check chrome://settings/cookies (or chrome://settings/trackingProtection)
for user settings that block third-party cookies,
that limit third-party cookies,
or that allow third-party cookies for specific sites.
Likewise, check chrome://settings/content/siteData
for settings that allow or block data storage (including cookies) from individual
domains.
chrome://policy
If you're in a Chrome Enterprise environment, policies in place on your browser may result in an experience for you that's different from what your users encounter — and the other way around. For testing, you might want to consider using a virtual machine or a device that's not managed.
The chrome://policy page displays policies set for browsers managed by a Chrome Enterprise
installation.
Chrome Enterprise Policies explains how policies can be set to block third-party cookies or allow them for specific sites.
Chrome DevTools
The Issues, Application and Network panels provide information about cookies, and show if third-party cookies are blocked by the browser.
- Audit your use of cookies explains how to assess third-party cookie usage on your site.
- View, add, edit, and delete cookies shows how to work with cookies in Chrome DevTools.
Chrome DevTools documentation provides more detail about how to add, edit and delete cookies, and how to identify and inspect third-party cookies.
Privacy Sandbox Analysis Tool (PSAT)
The PSAT Chrome extension adds tooling to Chrome DevTools to help understand cookie usage and provide guidance on new privacy-preserving Chrome APIs.
PSAT also provides a command line interface.
- Learn more, file issues and make feature requests: github.com/GoogleChromeLabs/ps-analysis-tool
Sites for testing
The Privacy Sandbox team maintains several sites to support third-party cookie testing:
- Set a third-party cookie: third-party-cookies.glitch.me
- Debug Chrome-facilitated testing settings: chrome-facilitated-testing.glitch.me
Privacy Sandbox Demos provides two linked sites to help you experiment with a variety of core user journeys and use cases, and understand how these are affected by third-party cookie restrictions.
Change the Chrome client or profile
A Chrome client corresponds to an installation on a device: a user data directory.
Each Chrome profile is a subdirectory within the user data directory.
If you run Chrome from the command line, you can set the user data directory with the --user-data-dir flag.
That means you can have a separate user data directory for development, with its own profile subdirectories. Creating a new user data directory makes Chrome behave as if it had been freshly installed, which can be helpful for debugging profile-related issues.
To run Chrome from the command line with a new temporary user directory, use the following flag:
--user-data-dir=$(mktemp -d)