What changed in third-party cookie support in Chrome in 2025?

What “third-party cookie support” means in Chrome

A cookie is a small piece of data that a website asks a browser to store and return later. A first-party cookie belongs to the site a visitor is currently viewing. A third-party cookie comes from a different domain embedded in, or otherwise involved with, that page. For example, a video player hosted by another company may try to set a cookie while appearing inside a news article.

“Support” can mean two different things. Chrome may allow a cookie under its browser rules, but the website or embedded service still has to choose to set it and use it. Conversely, Chrome may restrict a cookie even when a service requests it. A cookie’s outcome therefore depends on both the browser and the particular page or service.

That distinction matters. A site owner cannot infer that every third-party cookie works simply because Chrome is installed on a visitor’s device.

The 2025 change: Chrome’s approach to third-party cookies

Google’s stated direction changed from its earlier plan for a broad phase-out of third-party cookies in Chrome. In 2025, Google said it would maintain its existing approach to user choice rather than introduce a new standalone prompt for all Chrome users or impose a universal removal by a newly announced date.

So, what changed in third-party cookie support in Chrome in 2025? The key change was the direction of the browser policy, not a switch that instantly removed every third-party cookie from every Chrome session. Earlier discussions often treated a universal phase-out as the expected endpoint. The 2025 position instead left cookie behavior dependent on Chrome’s controls, user choices, and other protections that may apply to a particular context.

This does not mean that third-party cookies are guaranteed to work for everyone. Users can adjust privacy settings, browser features can limit access in particular situations, and websites can change how they rely on cookies.

For a site team, the practical message is narrower than “cookies are back” or “cookies are gone.” Check the actual experience in the Chrome versions and configurations your visitors use, and record which settings were active during each test.

What users may notice when browsing

Two people using Chrome can see different results on the same page. One may be signed in to an embedded service and have a setting that permits its cookie; another may have changed privacy controls or installed an extension that blocks the same request. The page can still load for both, while a feature such as a saved video position or embedded account status behaves differently.

Browser choice is only one part of the picture. Chrome’s settings, privacy protections, extensions, and the site’s own implementation can all affect whether a third-party cookie is available. A page may also depend on an external service that has its own requirements. If that service changes its code, the visible effect may appear on the host site even though the host site’s own cookies are unchanged.

Users may encounter a sign-in prompt where they expected to stay signed in, or see an embedded widget ask them to open the provider’s site. Those symptoms do not identify the cause on their own. A network failure, expired login, blocked script, or cookie restriction can produce similar results, so support teams should gather the browser version, relevant settings, page URL, and steps to reproduce.

When a problem involves account data or a form, treat the report as a site reliability issue as well as a privacy question. Teams reviewing broader protection measures can also consult this guide to website security.

What website teams may notice in testing

Start with features that depend on a service hosted on a different domain. Common examples include embedded video, a payment component, a customer support chat, a social sign-in button, or a booking calendar. Test the feature from a clean browser profile as well as a normal profile, because an existing login or stored cookie can hide a failure.

A useful test records the exact setup: Chrome version, operating system, profile state, privacy settings, installed extensions, page URL, and the action that failed. Then repeat the test with one variable changed. If a sign-in flow works in a clean profile but not in a profile with stricter settings, the comparison gives engineers a useful lead without assuming that every visitor has the same configuration.

Chrome’s developer tools can help identify requests to other domains and show whether a browser reports a cookie as blocked or restricted. Inspect the relevant page while reproducing the issue; do not rely only on a developer’s logged-in session. For a payment flow, for instance, test the complete sequence from selecting a product through returning to the confirmation page, not just whether the payment frame appears.

Keep a short inventory of third-party features and their fallback behavior. If an embedded booking tool cannot retain a session, can the visitor open it in a separate tab? If social sign-in fails, is there another way to access the account? Clear instructions and a working alternative can prevent a browser-specific issue from becoming a dead end.

These checks are separate from analytics migration and consent-banner configuration. The aim here is to determine whether a user-facing feature depends on third-party cookie behavior and what happens when that dependency is unavailable.

Why the same site can behave differently for different visitors

A visitor’s browser profile is not a neutral test environment. It may contain saved cookies, a signed-in account, site-specific permissions, or an extension that changes how requests are handled. A second visitor may have none of those, even if both report using the same Chrome release.

Embedded services add another layer. A video provider, identity service, or customer support platform may set cookies on its own domain, and the host site does not control every detail of that provider’s behavior. The embedded service may also use browser APIs or fallback methods that behave differently from cookies. When documenting a failure, separate what the host page does from what the external service does.

Chrome-specific restrictions can depend on the user’s settings and the situation in which a cookie is accessed. Avoid broad claims such as “Chrome blocks all third-party cookies” unless the tested configuration and policy actually support that statement.

A practical bug report should include a comparison: one affected profile, one control profile, the same page, and the same steps. That gives the team a way to distinguish a browser setting from a recent site release or a service outage.

Related terms

• Third-party cookie: A cookie associated with a domain other than the site currently shown in the browser. An embedded service may request one while a visitor is on the host site.

• Cookie deprecation: A planned reduction or removal of browser support for a type of cookie. The term describes a policy direction or change, not proof that every user’s browser has already stopped accepting that cookie.

• Tracking protection: Browser features or settings intended to limit tracking, which may affect cookies or other forms of cross-site data access. Its exact scope varies by browser, configuration, and current implementation.

• Privacy Sandbox: Google’s collection of proposals and technologies intended to support certain online advertising and measurement functions with different approaches to privacy. It is not another name for third-party cookies, and a Privacy Sandbox feature is not the same thing as a cookie setting.

These terms describe different layers: the cookie itself, a policy change, a browser protection, and a set of proposed technologies. Keeping them separate helps a support ticket say what actually happened instead of blaming every cross-site issue on “cookie deprecation.”

Examples: interpreting common Chrome cookie scenarios

Example one: an embedded video works for one person. A visitor who has previously used the video provider may have an active session, while a colleague opening the same page in a fresh profile sees a prompt or a different playback experience. The first successful test does not prove that every Chrome visitor has the same cookie access or stored state.

Example two: sign-in succeeds on one laptop but not another. Both users may be on Chrome, yet one has a privacy extension or a site-specific setting that changes requests to the identity provider. Ask each user to repeat the same steps in a clean profile and report the result. Do not ask them to disable protections permanently; a temporary controlled comparison is enough to help diagnose the issue.

Example three: a site still sets a cookie after a browser policy announcement. A browser policy change does not automatically remove code from a website. The site may still request a cookie, and the browser may handle it differently depending on its current rules and the visitor’s configuration. If the cookie is no longer needed, the site team must remove or replace its own dependency rather than assume Chrome will do so for them.

Example four: the frame loads, but its saved state does not. A third-party widget may display correctly while failing to remember a visitor’s selection between visits. Record the frame’s domain, the action that should persist, and what happens after a reload. That evidence is more useful than simply reporting that “the widget is broken.”

Teams can compare observed site activity with a monitoring setup such as a website analytics and monitoring platform, while keeping browser-specific reproduction steps in the issue record. If a feature fails only for a subset of Chrome profiles, the settings and exact sequence are part of the bug—not incidental details.