Chrome Third-Party Cookies Deprecation (2026): Migration Guide

Chrome’s third‑party cookie phaseout moves a bunch of “it just works” integrations into the failure path: embedded support widgets lose sessions, SSO in iframes breaks, and cross‑site analytics tags see fragmented identifiers. The 2026 timeline matters less than the rollout behavior: features will fail for some percentage of users before they fail for everyone.

This guide is a migration playbook. It gives you a decision tree for CHIPS vs Storage Access API vs FedCM, a test strategy for gradual rollouts, and implementation patterns for React/TypeScript frontends with Node.js backends (sessions, embeds, identity flows, and production monitoring).

Contents

• What actually breaks when third‑party cookies go away
• Decision tree: CHIPS vs Storage Access API vs FedCM
• Step‑by‑step migration plan (phased)
• Testing strategy: flags, rollouts, synthetic checks, and fallbacks
• Implementation patterns (React/TypeScript + Node.js)
• Operational guardrails: logging, metrics, alerting, and support playbooks
• FAQ: common edge cases and gotchas

What actually breaks when third‑party cookies go away

Third‑party cookies are cookies set in a third‑party context: an iframe, an image request, a script request, or a fetch/XHR where the cookie domain is not the current top‑level site. Deprecation means the browser stops sending and/or setting those cookies by default, even if you did everything “right” historically (SameSite=None; Secure).

Breakage patterns you’ll see in production

Baseline constraints you can’t dodge

• Partitioned vs unpartitioned storage: CHIPS gives you third‑party cookies, but partitioned by top‑level site. That means you don’t get cross‑site identity via that cookie.
• User gesture requirements: Storage Access API is intentionally frictional; you don’t get unpartitioned access silently in most cases.
• Identity flows are being redesigned: FedCM replaces a lot of third‑party cookie based “silent SSO” patterns. If you’re an IdP or relying on one, treat FedCM as the primary path, not a fallback.

Docs to keep open while you implement:

• Chrome Privacy Sandbox: Third‑party cookie phaseout / deprecation timeline (Google): https://privacysandbox.com/
• CHIPS (Cookies Having Independent Partitioned State) explainer: https://github.com/WICG/CHIPS
• Storage Access API (MDN): https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API
• FedCM (Federated Credential Management) docs: https://developer.chrome.com/docs/privacy-sandbox/fedcm/

Decision tree: CHIPS vs Storage Access API vs FedCM

Pick the primitive based on the job you’re trying to do. Most teams get stuck because they start from “how do I keep my cookie working?” instead of “what property do I need: embedded session, cross‑site identity, or privileged storage access?”

Fast decision tree

Are you doing user authentication / SSO across sites?
  - Yes => Use FedCM (plus top-level redirects as needed)
  - No => Continue

Is your content embedded cross-site (iframe) and needs a session/state?
  - Yes => Use CHIPS (Partitioned cookies)

Do you truly need unpartitioned cookie/storage access inside a third-party iframe?
  - Yes => Use Storage Access API (expect user gesture, UX work)
  - No => Stay with CHIPS + postMessage/token exchange

Trade-offs table

Concrete recommendations (opinionated)

• Embedded widget session (support/chat, BI embed, payments): start with CHIPS. Only reach for Storage Access API if partitioning breaks a hard requirement.
• “Login with X” / enterprise SSO / consumer identity: implement FedCM. Keep top-level OAuth redirects as a compatibility path.
• Cross-site tracking or attribution: don’t try to rebuild this with cookies via Storage Access API. Move to first-party/server-side measurement and (if needed) Privacy Sandbox APIs.

Step‑by‑step migration plan (phased)

Do this in phases so you can measure impact and roll forward without breaking auth for a portion of users.

Phase 0 — inventory and classify cookie usage

1. List every cookie your app sets (domain, path, SameSite, Secure, HttpOnly, Max-Age).
2. Identify third‑party contexts:
   • Anything inside iframes on other sites
   • Any API called cross-site expecting cookies
   • Any hidden iframes used for silent login/refresh
3. Classify into buckets:
   • Embedded session (widget/app state)
   • Federated identity (SSO, login)
   • Analytics/ads

Phase 1 — make embedded sessions partition-friendly (CHIPS)

If you run an embedded widget at widget.example that is framed into many customer sites, the right mental model is: one session per customer site. Stop trying to share a single cookie across all top-level sites.

Cookie changes: mark cookies as partitioned, and keep SameSite=None; Secure for third-party embedding.

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

On the server, treat the session as scoped to a partition. Practically, that means you may see multiple sessions per user (one per embed site). If you need a shared account identity, move that to explicit login/token flow, not a cookie shared across embeds.

Phase 2 — add Storage Access API only where partitioning is not acceptable

Storage Access API is for cases like: “User is logged into id.example in a top-level tab, and our embedded content on other sites must access that same login state.” This is usually an identity problem (FedCM) or a product design smell. Use it when you truly need it and you can design a UX around it.

Plan for these behaviors:

• You need to call document.hasStorageAccess() and document.requestStorageAccess() inside the iframe.
• requestStorageAccess() may require a user gesture and may prompt/deny.
• You need a fallback if access is denied (e.g., “Open in new tab to continue”).

Phase 3 — migrate federated login to FedCM

If your silent SSO depended on third‑party cookies in iframes (common with older OAuth/OIDC “check session” iframes), you need a new primary path. FedCM is Chrome’s intended replacement for many federated identity use cases, with browser-managed UX and reduced tracking surface.

Implementation detail depends on whether you are:

• Relying party (RP): your site uses an IdP to log users in.
• Identity provider (IdP): you operate the identity service.

Either way, keep an OAuth top-level redirect flow as a compatibility path for browsers/environments where FedCM isn’t available or isn’t configured.

Testing strategy: flags, rollouts, synthetic checks, and fallbacks

The worst failure mode is “auth fails for 1% of users, support can’t reproduce, and metrics don’t show it.” You need deterministic repro environments and production instrumentation.

1) Build a reproducible local/dev test matrix

For Chrome-specific toggles and experiments, keep a small internal doc pointing to the exact flags/version your team uses. Chrome flags churn; relying on tribal memory is how you lose a week.

2) Validate against gradual rollout behavior

Expect a world where some users have 3PC blocked and others don’t. Your app needs to choose correct behavior per-request, not per-release.

What to implement:

• Server-side detection by outcome: treat 401/403 from embedded APIs as a signal that cookies weren’t sent, not necessarily “user is logged out”.
• Client-side detection: in iframes, check whether the expected cookie-backed endpoint works; if not, fall back to token/postMessage flow or a prompt to open a top-level page.
• Per-top-level partition testing: load the same iframe on two different top-level sites and verify you get two different sessions when using CHIPS.

3) Synthetic monitoring that catches cookie breakage

Real user monitoring will tell you something is wrong; synthetic checks tell you exactly where it broke.

Use Playwright (or similar) to run a daily/hourly job that:

• Loads publisher-a.test embedding your iframe
• Completes a minimal auth/session path
• Reloads and asserts session continuity
• Repeats on publisher-b.test and asserts partition isolation (for CHIPS)
• Runs with third-party cookies blocked to simulate the deprecation path

// playwright.config.ts: run with a persistent context and cookie blocking settings
import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: {
    // Prefer explicit test domains via hosts/DNS; local "localhost" won't exercise eTLD+1 logic.
    baseURL: 'https://publisher-a.test',
  },
});

For Chrome, you can launch with explicit args that influence cookie behavior, but teams often get better coverage by using Chrome’s settings/policies in dedicated test profiles and documenting them. Either way, treat this as a regression suite you can run on demand when Chrome versions change.

4) Fallback behavior: don’t strand the user

Your fallback strategy should be explicit in code, not left to browser defaults.

• Embedded widget: if cookie-backed session API returns 401, switch to a one-time token bootstrap via postMessage from the host page, or show a “Continue” button that opens a top-level login.
• SSO: if FedCM is unavailable or fails, fall back to top-level OAuth redirect login.
• Storage access denied: present a clear action: “Open in a new tab to continue”, then complete login in top-level context.

If you also need coverage on other Chrome platform changes in the same timeframe, keep your migration workstreams separate but your test harness shared. See: Chrome geolocation API changes 2025-2026: production migration playbook.

Implementation patterns (React/TypeScript + Node.js)

This section assumes a common setup:

• React/TypeScript frontend
• Node.js backend (Express/Fastify style)
• An embedded iframe widget served from https://widget.example and embedded on customer sites
• Auth either first-party (your own accounts) or federated (OIDC)

Pattern A — CHIPS for iframe widget sessions (recommended default)

Backend: set a partitioned session cookie

// Express example
import express from 'express';
import cookieParser from 'cookie-parser';

const app = express();
app.use(cookieParser());

app.post('/api/widget/session', (req, res) => {
  // Create a session in your store keyed by sessionId
  const sessionId = crypto.randomUUID();

  // Critical attributes for 3P embedding + CHIPS
  res.cookie('widget_session', sessionId, {
    httpOnly: true,
    secure: true,
    sameSite: 'none',
    // Many cookie libs don’t yet have a first-class "Partitioned" flag.
    // If yours doesn't, set the header manually.
  });

  // If your framework can't add Partitioned via res.cookie, overwrite:
  const existing = res.getHeader('Set-Cookie');
  const cookies = Array.isArray(existing) ? existing : existing ? [String(existing)] : [];
  // Replace the last cookie with a Partitioned attribute.
  if (cookies.length > 0) {
    const last = cookies[cookies.length - 1];
    cookies[cookies.length - 1] = last + '; Partitioned';
    res.setHeader('Set-Cookie', cookies);
  }

  res.json({ ok: true });
});

Server-side session model change: don’t assume a single global session per user across embeds. Store enough context (top-level site, embed origin, customer account id) to debug “it works on one customer site but not another”.

Frontend (iframe app): bootstrap and verify cookie-backed session

// iframe app code (widget.example)
export async function ensureSession(): Promise<void> {
  const resp = await fetch('/api/widget/me', {
    credentials: 'include',
  });

  if (resp.ok) return;

  // If cookie wasn't sent, /me will 401. Attempt a session creation call.
  const create = await fetch('/api/widget/session', {
    method: 'POST',
    credentials: 'include',
  });

  if (!create.ok) {
    // Trigger fallback: ask host page for a bootstrap token, or show "Open in new tab".
    throw new Error('WIDGET_SESSION_UNAVAILABLE');
  }
}

Host page: optional token bootstrap via postMessage

CHIPS solves “I need a session inside the iframe”. It does not solve “I need to know the user identity from the embedding site”. For that, use an explicit handoff from the host page.

// host page on publisher.com
const iframe = document.getElementById('support-widget') as HTMLIFrameElement;

window.addEventListener('message', async (event) => {
  if (event.origin !== 'https://widget.example') return;
  if (event.data?.type !== 'REQUEST_BOOTSTRAP_TOKEN') return;

  const tokenResp = await fetch('/api/widget-bootstrap-token', { method: 'POST' });
  const { token } = await tokenResp.json();

  iframe.contentWindow?.postMessage(
    { type: 'BOOTSTRAP_TOKEN', token },
    'https://widget.example'
  );
});

// iframe app receives token and exchanges it for a session
window.addEventListener('message', async (event) => {
  if (event.origin !== 'https://publisher.com') return; // use a dynamic allowlist in real code
  if (event.data?.type !== 'BOOTSTRAP_TOKEN') return;

  await fetch('/api/widget/exchange', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    credentials: 'include',
    body: JSON.stringify({ token: event.data.token }),
  });
});

This “token exchange” pattern gives you deterministic control over identity and avoids relying on third-party cookies as an identity transport.

Pattern B — Storage Access API for unpartitioned access (use sparingly)

Use this when the iframe needs to access the same login state the user has on widget.example as a top-level site (unpartitioned). You will need a UI moment to request access.

// iframe app code
export async function ensureStorageAccess(): Promise<boolean> {
  // Guard for browsers that don’t implement it.
  if (!('hasStorageAccess' in document) || !('requestStorageAccess' in document)) {
    return false;
  }

  // @ts-expect-error: TS lib dom may not include these depending on version
  const has = await document.hasStorageAccess();
  if (has) return true;

  return false;
}

export async function requestStorageAccessFromUserGesture(): Promise<boolean> {
  try {
    // Must be called from a click/tap handler in many browsers.
    // @ts-expect-error
    await document.requestStorageAccess();
    return true;
  } catch {
    return false;
  }
}

UX pattern that works: render the widget in a limited state with a “Continue” button. On click, call requestStorageAccess(). If granted, reload the widget and proceed. If denied, show “Open in new tab”.

Pattern C — FedCM for login (RP-side example)

FedCM is the browser-managed alternative to “hidden iframe checks a cookie at the IdP”. At a high level, your frontend requests a credential, the browser mediates account selection/consent, and you exchange the result with your backend.

// React hook style (RP)
// The concrete shape of the FedCM API is evolving; follow Chrome docs for current fields.

type FedCMResult = {
  token: string; // e.g., an ID token or an authorization code depending on your configuration
};

export async function fedcmSignIn(): Promise<FedCMResult> {
  if (!('credentials' in navigator)) throw new Error('FEDCM_UNSUPPORTED');

  // @ts-expect-error - TS DOM typings may lag FedCM
  const cred = await navigator.credentials.get({
    identity: {
      providers: [
        {
          configURL: 'https://idp.example/.well-known/fedcm.json',
          clientId: 'your-client-id',
        },
      ],
    },
  });

  if (!cred) throw new Error('FEDCM_NO_CREDENTIAL');

  // @ts-expect-error
  return { token: cred.token };
}

// Node.js backend: exchange FedCM token for your session
app.post('/api/auth/fedcm', express.json(), async (req, res) => {
  const { token } = req.body as { token: string };

  // Validate token (JWT verification, issuer checks, nonce/audience checks)
  // Or exchange authorization code for tokens depending on your design.

  const sessionId = crypto.randomUUID();
  // Set a first-party cookie for your app (top-level context)
  res.cookie('app_session', sessionId, {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
  });

  res.json({ ok: true });
});

Operationally: FedCM introduces new failure modes (user cancels the browser prompt, IdP misconfiguration, blocked third-party endpoints). Treat it like a primary auth system with metrics and alerts, not a UI flourish.

Session handling rules of thumb (keep them boring)

• Top-level app session: first-party cookie (SameSite=Lax unless you have a reason not to).
• Embedded widget session: CHIPS partitioned cookie (SameSite=None; Secure; Partitioned).
• Identity transfer between host and iframe: explicit token exchange via postMessage, not shared cookies.
• Cross-site API calls: avoid cookie auth. Use bearer tokens with narrow scope and short TTL if you must call cross-site.

Related platform churn tends to cluster. If your team is already firefighting browser changes, keep a running playbook per browser release. Example: Chrome 144 geolocation API changes and Topics deprecation.

Operational guardrails: logging, metrics, alerting, and support playbooks

Cookie deprecation failures often look like generic auth failures. If you don’t tag them, they’ll get mis-triaged as “random logout bugs”.

Instrument the failure modes explicitly

Node.js example: structured auth failure logging

import pino from 'pino';

const log = pino({ level: process.env.LOG_LEVEL ?? 'info' });

app.use((req, _res, next) => {
  // Capture embedding context when present (e.g., via custom headers from your host SDK)
  (req as any).ctx = {
    requestId: req.headers['x-request-id'] ?? crypto.randomUUID(),
    embedOrigin: req.headers['x-embed-origin'],
  };
  next();
});

app.use((err: any, req: any, res: any, _next: any) => {
  log.error({
    msg: 'request_failed',
    requestId: req.ctx?.requestId,
    path: req.path,
    method: req.method,
    status: res.statusCode,
    embedOrigin: req.ctx?.embedOrigin,
    error: { name: err.name, message: err.message },
  });

  res.status(500).json({ ok: false });
});

Alerting that matches rollout reality

• Alert on rate-of-change, not raw counts. Rollouts create step changes by cohort.
• Break down by embed origin (customer site) so you can see if a specific integration is failing due to CSP, sandboxing, or iframe attributes.
• Break down by Chrome version/channel (stable/beta/canary) to catch regressions early.

If you run SSO across browsers, track the non-Chrome tail too. Firefox and Safari have been stricter on third-party storage for a while, and enterprise setups can be even stricter. See: Firefox 148: location ancestorOrigins SSO break.

FAQ: common edge cases and gotchas

Do I need CHIPS if I already use SameSite=None; Secure?

Yes for embedded sessions, because SameSite=None only marks intent to send cookies in a third-party context. Deprecation removes the underlying behavior; CHIPS is the replacement mechanism for “cookie in third-party context” where partitioning is acceptable.

Can I use Storage Access API to keep cross-site tracking working?

No as a general strategy. Storage Access API is intentionally designed to require user interaction and be hard to scale as a passive tracking mechanism. If your business depends on cross-site tracking, you need to move the design to first-party/server-side measurement or Privacy Sandbox APIs.

My widget is embedded in a sandboxed iframe. Does that change anything?

Yes. A sandboxed iframe can block storage access, popups, and navigation depending on flags. Audit your embed code and document the required iframe attributes. Expect to need allow-scripts and often allow-same-origin (with security trade-offs) plus explicit allowances for popups if you fall back to top-level auth.

We do OIDC with silent refresh in an iframe. Is FedCM mandatory?

If your IdP and target browsers support FedCM, treat it as the clean replacement for silent iframe refresh. For compatibility, keep top-level redirect and refresh-token patterns where appropriate (and where your threat model allows refresh tokens in the browser).

How do I explain “partitioned sessions” to product?

“The browser will keep separate login state for our widget per site it’s embedded in. A user can be logged into the widget on one customer site and not logged in on another unless we implement an explicit login handoff.” Product can then decide if they want a unified identity experience and pay the UX cost.

Bottom Line

For embedded cross-site experiences, default to CHIPS and design around per-top-level-site sessions. Use Storage Access API only when you have a hard requirement for unpartitioned access and you can afford a user-gesture UX. For authentication and SSO, implement FedCM and keep top-level redirects as the compatibility path. Then treat rollout as an ops problem: synthetic checks, explicit logging of “cookie missing” failures, and fallbacks that keep users unblocked.

If you’re managing multiple browser/platform migrations at once, keep a single test harness and separate feature playbooks. For adjacent changes, see React 19.2.4 server security hardening.