Third-party cookies: what Chrome’s reversal really changed and which Privacy Sandbox APIs are going away

That description is no longer accurate in 2026.

Chrome did not carry out a universal mandatory third-party-cookie shutdown according to the old schedule. Google decided to maintain its current model, in which users can manage third-party-cookie access through Chrome settings. The company also abandoned the plan for a new standalone third-party-cookie prompt.

That does not mean the web has returned to its pre-Privacy-Sandbox state.

Third-party cookies may still be unavailable because of:

• user choice;
• Incognito mode;
• Chrome Enterprise policies;
• browser-specific restrictions;
• site settings;
• Chrome test cohorts;
• partitioning and tracking-protection mechanisms.

At the same time, Google decided to retire a large part of Privacy Sandbox, including Topics, Protected Audience, Attribution Reporting, Shared Storage and Related Website Sets. Functional building blocks such as CHIPS, the Storage Access API, FedCM, storage partitioning and Private State Tokens remain supported.

The practical conclusion: Chrome’s reversal does not justify designing sign-in, embedded widgets, analytics or payments on the assumption that unpartitioned third-party cookies will always be available. A 2026 architecture must support both runtime states: access granted and access blocked.

The status and sources were verified on 23 July 2026.

TL;DR

Question	2026 answer
Did Chrome disable third-party cookies for everyone?	No
Is Chrome still planning a new standalone prompt?	No
Can users block them?	Yes
Are they blocked by default in Incognito?	Yes
Should an application assume availability?	No
Is all of Privacy Sandbox disappearing?	No
Are Topics and Protected Audience being retired?	Yes
Is CHIPS still supported?	Yes
Does the Storage Access API remain?	Yes
Does FedCM remain?	Yes
Does SameSite=None; Secure guarantee access?	No
Is there one removal date for every API?	No

1. What is a third-party cookie?

A cookie is a browser-stored value sent according to rules covering domain, path, protocol, lifetime and the SameSite attribute.

A cookie is third-party when it is used in the context of a site that differs from the top-level site shown in the browser tab.

Example:

The user opens:
https://shop.example

The page embeds:
https://chat.vendor.example/widget

If the embedded widget attempts to use an unpartitioned cookie belonging to chat.vendor.example, it is doing so in a third-party context.

A typical cookie intended for cross-site requests looks like this:

Set-Cookie: widget_session=abc123;
  SameSite=None;
  Secure;
  HttpOnly;
  Path=/

SameSite=None permits cross-site sending, and modern browsers require Secure with SameSite=None.

Those attributes are necessary technical conditions, not a guarantee. Browser policy or user settings may still block the cookie.

2. How did Chrome’s plan change?

Stage 1: preparing for a cookie-free model

Privacy Sandbox began as a collection of proposals intended to reduce cross-site tracking while preserving use cases involving advertising, measurement, fraud prevention and identity.

In January 2024, Chrome began restricting third-party cookies for 1% of users as part of the Tracking Protection test.

Stage 2: abandoning universal phase-out

In July 2024, Google changed direction. Instead of a universal removal, it proposed an approach centred on user choice.

On 22 April 2025, Google clarified the final direction:

• Chrome would maintain its current user-choice approach;
• a new standalone prompt would not be rolled out;
• users would continue managing cookies in Privacy and Security settings;
• Incognito would continue blocking third-party cookies by default.

This is the core Chrome reversal.

Stage 3: shrinking Privacy Sandbox

On 17 October 2025, Google announced that it would retire a large set of Privacy Sandbox technologies after evaluating ecosystem feedback and adoption.

In January 2026, Chrome 144 release notes listed deprecation and planned removal for Private Aggregation, Shared Storage and Protected Audience.

The change is broader than Chrome 144. The official status page covers additional technologies, each moving through Chrome or Android lifecycle processes.

3. What does “maintaining the current approach” mean?

It does not mean:

• cookies are guaranteed in every Chrome installation;
• unrestricted cross-site tracking has returned;
• storage partitioning has been cancelled;
• Chrome, Safari and Firefox behave identically;
• an existing iframe or SSO integration is safe without testing.

It means Chrome did not replace the current model with a global shutdown and a new prompt for the entire user base.

Chrome documentation still lists several reasons cookies may be blocked:

• user settings;
• browser restrictions;
• testing flags;
• Chrome Enterprise policy.

The same page, updated on 18 December 2025, still describes a 1% test group for which third-party cookies are restricted by default.

For developers, availability is a runtime condition:

third-party cookie availability = a runtime capability,
not a guaranteed property of “using Chrome”

4. Which Privacy Sandbox technologies are being retired?

The official status uses several categories:

• Deprecate and remove: an API is intended for deprecation and removal.
• Discontinue: work on the feature is ending.
• Do not launch: the technology will not ship.
• Scheduled for phaseout: gradual retirement is planned.

These should not be collapsed into a fictional single “Privacy Sandbox shutdown date”.

Main web technologies marked for deprecation and removal

Technology	Original purpose	Status
Attribution Reporting API	attribution measurement without cross-site identifiers	deprecate and remove
Aggregation Service	aggregation for Attribution Reporting	scheduled for phaseout
Topics API	browser-derived advertising interests	deprecate and remove
Protected Audience API	on-device interest-group advertising auctions	deprecate and remove
Private Aggregation API	aggregate cross-site measurements	deprecate and remove
Shared Storage API	cross-site storage with constrained operations	deprecate and remove
SelectURL	choosing a URL variant based on Shared Storage	retired with Shared Storage
Related Website Sets	declaring groups of related domains	deprecate and remove
requestStorageAccessFor()	requesting access on behalf of a related-site resource	deprecate and remove
Related Website Partition	shared partition for related sites	discontinue

Technologies being discontinued or not launched

Technology	Status
IP Protection	discontinue / scheduled for phaseout
Partitioned Popins	discontinue
Fenced Storage Read	do not launch
Private Proofs	do not launch
Probabilistic Reveal Tokens	do not launch
Script Blocking	do not launch

Android Privacy Sandbox

Google is also retiring:

• Attribution Reporting;
• On-Device Personalization;
• Protected App Signals;
• Protected Audience;
• SDK Runtime;
• Topics.

5. What changed in Chrome 144?

Chrome 144, released to Stable in January 2026, included formal deprecation entries for:

• Private Aggregation API;
• Shared Storage API;
• Protected Audience API.

The release notes describe planned deprecation and removal. They do not mean every component stopped functioning instantly in every installation.

A typical lifecycle may include:

1. an Intent to Deprecate;
2. documentation and console warnings;
3. a default-state change;
4. code removal;
5. a possible transition period or deprecation trial.

Teams should track Chrome Platform Status and release notes rather than relying on one date from a secondary article.

6. What remains supported?

Privacy Sandbox is not disappearing as one indivisible package. Several useful platform mechanisms remain.

CHIPS

CHIPS allows a cookie to opt into partitioned storage through the Partitioned attribute. The browser creates a separate cookie jar per top-level site.

Set-Cookie: __Host-widget_session=abc123;
  Secure;
  HttpOnly;
  Path=/;
  SameSite=None;
  Partitioned

When chat.vendor.example is embedded on:

shop-a.example
shop-b.example

it receives separate partitions. A cookie set under shop-a.example is not available when the same widget is embedded under shop-b.example.

CHIPS fits use cases such as:

• support chat;
• maps;
• embedded payments;
• per-site component state;
• embedded resources needing a session isolated to one top-level site.

It is not a replacement when one identifier must be shared across unrelated sites. Preventing that sharing is the privacy property.

Storage Access API

The Storage Access API allows an embedded document to check for and request access to unpartitioned cookies.

async function ensureStorageAccess() {
  if (await document.hasStorageAccess()) {
    return true;
  }

  try {
    await document.requestStorageAccess();
    return true;
  } catch {
    return false;
  }
}

Access:

• may require user activation;
• may show a prompt;
• is subject to browser policy;
• may be denied;
• requires a secure context;
• may be blocked by Permissions Policy.

requestStorageAccess() is not an automatic privacy bypass.

FedCM

The Federated Credential Management API supports federated identity flows without relying on third-party cookies or traditional navigation redirects.

FedCM is relevant to:

• sign-in with an identity provider;
• One Tap experiences;
• federated account creation;
• browser-mediated RP and IdP flows.

It is not a universal cookie replacement. It does not solve widget state, analytics or every OpenID Connect capability.

Storage and Network State Partitioning

Chrome continues to support partitioning of storage and network state, limiting the ability to connect user activity across top-level sites.

Private State Tokens

Private State Tokens remain supported as a mechanism for passing limited trust signals without ordinary cross-site user tracking.

Other retained features

The official status also lists:

• bounce-tracking mitigations;
• Fenced Frames;
• the frame-ancestors directive;
• User-Agent Client Hints and User-Agent reduction.

These are separate privacy and security mechanisms, not generic replacements for cookies.

7. Is SameSite=None; Secure enough?

No.

Set-Cookie: session=abc;
  SameSite=None;
  Secure

means the cookie is eligible for cross-site sending when the browser permits unpartitioned third-party cookies.

It does not mean:

• the user has not blocked them;
• Incognito will allow them;
• Safari and Firefox will behave like Chrome;
• enterprise policy will permit them;
• the iframe has Storage Access;
• tracking protections will not intervene.

Applications must detect actual access.

8. How can an embed detect cookie access?

Chrome documents two primary methods.

document.hasStorageAccess()

const hasAccess = await document.hasStorageAccess();

This lets an embedded document check whether it has access to unpartitioned cookies.

Sec-Fetch-Storage-Access

From Chrome 133, credentialed requests may include:

Sec-Fetch-Storage-Access: active

Possible values are:

• none;
• inactive;
• active.

Server-side example:

const storageAccess =
  request.headers.get("sec-fetch-storage-access");

if (storageAccess !== "active") {
  // Do not assume unpartitioned third-party-cookie access.
}

What should not be used as the only test?

navigator.cookieEnabled

It does not reliably describe whether a specific iframe can use a specific third-party cookie. It mainly reflects general cookie support.

9. What about requestStorageAccessFor()?

It is different from:

document.requestStorageAccess()

requestStorageAccessFor() was an extension associated with Related Website Sets, enabling a top-level site to request access on behalf of a related-site resource.

Because Related Website Sets is being retired, requestStorageAccessFor() is also marked for deprecation and removal.

MDN labels the method deprecated and non-standard.

The standard requestStorageAccess() remains the supported cross-browser direction for embedded documents needing unpartitioned state.

10. Consequences for authentication

Flows most at risk are those that assume an identity provider embedded in an iframe can always read its own cookie.

Use case	More durable approach
federated sign-in	FedCM or a well-designed top-level OAuth/OIDC flow
first-party application session	first-party cookie on the application domain
embed requiring an existing account	Storage Access API with clear UX
independent widget state	CHIPS
parent ↔ iframe communication	postMessage() with strict origin validation
communication between owned backends	server-side sessions and scoped tokens

Do not automatically move session tokens into localStorage. That does not solve every cross-site problem and may increase the impact of XSS.

11. Consequences for analytics

Chrome’s reversal means cookies were not globally removed, but they remain an unstable measurement foundation.

Data availability may differ across:

• users who block cookies;
• normal and private modes;
• Chrome, Safari and Firefox;
• enterprise-managed devices;
• users with blocking extensions;
• consent states.

The existing Attribution Reporting API is being retired. Google says it will continue work on an interoperable attribution standard through the web-standards process.

That is not a guaranteed drop-in replacement.

A practical measurement architecture uses:

• first-party collection;
• consent where required;
• data minimisation;
• aggregation;
• modelling of missing data;
• privacy-controlled server-side collection;
• explicit coverage and uncertainty reporting.

12. Consequences for advertising

Three central advertising pillars are being retired:

• Topics;
• Protected Audience;
• Attribution Reporting.

Shared Storage, SelectURL, Private Aggregation and Aggregation Service are also affected.

A new strategic implementation should not be built solely around those APIs without checking their current lifecycle and migration path.

This does not mean the market has returned to one stable cookie-based model. Cookie availability remains fragmented, and other browsers apply their own tracking protections.

13. Consequences for widgets and embedded services

A typical widget:

<iframe src="https://support.vendor.example/widget"></iframe>

may need session recognition, preferences, access to an account and parent-page communication.

State isolated to one embedder

Use CHIPS.

Access to an existing unpartitioned session

Use the Storage Access API with a fallback and clear explanation.

Federated authentication

Consider FedCM.

Explicit data from the parent

Use postMessage() and strictly validate origin.

14. Auditing third-party cookies

Chrome recommends DevTools and the Privacy Sandbox Analysis Tool for auditing.

Step 1: inventory cookies

Field	Example
name	widget_session
setter	chat.vendor.example
context	iframe
purpose	conversation state
cross-site required?	yes
shared across sites?	no
alternative	CHIPS

Step 2: find SameSite=None

grep -R "SameSite=None" .

This will not find cookies set by third-party scripts, so DevTools and network logs remain necessary.

Step 3: test with blocking enabled

Chrome documents:

chrome://flags/#test-third-party-cookie-phaseout

and:

google-chrome --test-third-party-cookie-phaseout

The documentation still recommends this mode for breakage testing.

Step 4: test real journeys

• sign-in and sign-out;
• token refresh;
• payment;
• chat;
• maps;
• embedded media;
• consent;
• analytics;
• cross-domain checkout;
• account recovery.

Step 5: test other browsers

Chrome’s reversal did not change Safari or Firefox policies.

15. Progressive widget strategy

async function initializeWidget() {
  if ("hasStorageAccess" in document) {
    const hasAccess = await document.hasStorageAccess();

    if (hasAccess) {
      return startWithUnpartitionedSession();
    }
  }

  const partitionedSession = await tryPartitionedSession();

  if (partitionedSession) {
    return startWithPartitionedSession();
  }

  return startAnonymousMode();
}

After an explicit user action:

button.addEventListener("click", async () => {
  try {
    await document.requestStorageAccess();
    location.reload();
  } catch {
    showManualLoginFallback();
  }
});

The denied path is a normal product state, not an exceptional user failure.

16. What not to do

Do not assume Chrome’s reversal solved the dependency

Third-party cookies remain unpredictable.

Do not replace cookies with fingerprinting

Aggressive device-signal collection is not a privacy-preserving migration.

Do not automatically move sessions to localStorage

It may raise XSS risk and does not create safe cross-site sharing.

Do not use CHIPS for cross-site identity

CHIPS intentionally isolates state by top-level site.

Do not use Storage Access without a fallback

Permission can be denied.

Do not start a new project on a retiring API

Check Topics, Protected Audience, Attribution Reporting, Shared Storage and RWS before investing.

Do not confuse “deprecated” with “already gone”

Deprecation and removal are lifecycle stages. Check the browser version and Chrome Platform Status.

17. Recommended 2026 architecture

Standard application

• first-party session cookie;
• Secure;
• HttpOnly;
• appropriate SameSite;
• CSRF protection;
• no dependency on a cross-site iframe.

Embedded widget

• CHIPS for per-site isolated state;
• anonymous fallback;
• Storage Access only when an existing unpartitioned session is essential;
• validated postMessage() communication.

Federated sign-in

• FedCM where it fits;
• standard top-level OAuth/OIDC redirect fallback;
• first-party session after returning to the application.

Analytics

• first-party collection;
• consent and minimisation;
• explicit measurement of missing coverage;
• aggregation instead of promises of complete cross-site identity.

18. Migration checklist

Inventory

• List every cookie.
• Identify setter and domain.
• Identify first-party or third-party context.
• Document the business purpose.
• Identify the integration owner.
• Document the failure mode.
• Remove unused cookies.

Cookie security

• Secure on session cookies.
• HttpOnly where JavaScript does not need access.
• Minimal Domain.
• Minimal Path.
• Appropriate SameSite.
• Short lifetime.
• __Host- prefix where suitable.

Cross-site behaviour

• No assumption that SameSite=None guarantees access.
• hasStorageAccess() detection.
• Denial handling for requestStorageAccess().
• CHIPS for isolated state.
• FedCM for supported identity flows.
• Cookie-free fallback.
• Incognito test.
• Explicit blocked-cookie test.

Privacy Sandbox

• No new dependency on Topics.
• No new dependency on Protected Audience.
• Exit plan for Attribution Reporting API.
• Exit plan for Shared Storage and SelectURL.
• Exit plan for Private Aggregation.
• Exit plan for Related Website Sets.
• Remove requestStorageAccessFor().
• Monitor Chrome release notes.

Tests

• Normal Chrome.
• Chrome Incognito.
• Chrome with manual blocking.
• Safari.
• Firefox.
• Signed-in and signed-out.
• New and returning user.
• Embed on at least two top-level sites.
• Offline and API failure.
• Chrome Enterprise policy where relevant.

19. Useful POLPROG tools

• Website Health Check helps identify technical and performance issues.
• Security Headers Inspector checks CSP, HSTS and other response protections.
• DNS & SSL Inspector verifies domain and TLS configuration.
• FlowTrace helps trace requests, sessions and data through browser, CDN and backend.
• The POLPROG Knowledge Base contains further privacy, security and web-architecture material.

Verdict

Chrome did not execute the old plan for a global third-party-cookie shutdown. Users retain control, and Chrome did not deploy the planned standalone prompt.

That does not restore third-party cookies as a stable dependency.

In 2026:

• some users block them;
• Incognito blocks them by default;
• enterprise policies may restrict them;
• other browsers apply different rules;
• storage is increasingly partitioned;
• many advertising-oriented Privacy Sandbox APIs are being retired;
• CHIPS, Storage Access and FedCM remain.

The strongest architecture does not try to predict Chrome’s next decision. It works correctly whether unpartitioned third-party cookies are available or not.