Google's Third-Party Cookie U-Turn: What Developers Need to Know in 2026

Updated April 2026

Google cancelled third-party cookie deprecation in July 2024. If you stopped preparing, you stopped too early. Safari has blocked third-party cookies since 2017. Firefox blocks them by default since 2022. The problem didn't go away — Chrome just didn't join yet.

What actually happened

What didn't change — Safari and Firefox

Safari has ~19% global browser market share. Firefox has ~4%. That's roughly 1 in 4 users where your cross-site cookies are already failing — silently, with no error in your logs.

What Chrome 118+ changed (regardless of deprecation)

Even though Google didn't deprecate third-party cookies, Chrome 118 (October 2023) still enforced a change: SameSite=None cookies in third-party context now require the Partitioned attribute to work reliably.

# Before Chrome 118 — worked in third-party context
Set-Cookie: session=abc; SameSite=None; Secure

# After Chrome 118 — requires Partitioned for reliable third-party access
Set-Cookie: session=abc; SameSite=None; Secure; Partitioned

This is CHIPS — Cookies Having Independent Partitioned State. It's separate from deprecation. It's about how cookies are scoped when shared cross-site.

What developers actually need to do in 2026

1. Audit your cross-site cookies

Find every Set-Cookie header on your responses that uses SameSite=None. These are the cookies that need to work in third-party context.

# Check your Set-Cookie headers
curl -sI https://your-domain.com | grep -i "set-cookie"

# Or use the Cookie Partitioning Auditor:
# httpfixer.dev/cookies/

2. Add Partitioned to SameSite=None cookies

# Before — blocked in Safari, Firefox, and potentially Chrome
Set-Cookie: embed_session=abc; SameSite=None; Secure; Path=/

# After — works in all browsers that support CHIPS
Set-Cookie: embed_session=abc; SameSite=None; Secure; Partitioned; Path=/

3. Separate first-party from third-party cookies

Not all cookies need Partitioned. Only cookies that need to work when your domain is embedded in another site's context. First-party cookies (your own domain, your own users) are unaffected.

The Storage Access API — for Safari

For embedded iframes that need access to first-party cookies (not just partitioned cross-site cookies), the Storage Access API lets you request user permission:

// Inside your iframe — request storage access
// Required for Safari ITP compatibility in some embed scenarios
async function requestCookieAccess() {
  try {
    await document.requestStorageAccess();
    // Access granted — cookies now sent with requests
    console.log('Storage access granted');
  } catch (err) {
    // Denied or not supported — fall back to postMessage
    console.log('Storage access denied:', err);
  }
}

// Check if access is already granted (Safari 16.1+)
const hasAccess = await document.hasStorageAccess();
if (!hasAccess) {
  await requestCookieAccess();
}

What the Privacy Sandbox means for developers

Google's Privacy Sandbox APIs (Topics, Protected Audience, Attribution Reporting) are still available and being developed. They're primarily relevant for advertising use cases, not session management or auth.

For most web developers — not ad-tech — the Privacy Sandbox APIs are not relevant. The relevant changes are:

• CHIPS (Partitioned cookies) — for any cross-site cookie
• Storage Access API — for embedded iframes needing first-party cookie access
• Related Website Sets — for closely related domains sharing cookies

Quick checklist — 2026 cookie audit

# 1. Find SameSite=None cookies without Partitioned
curl -sI https://your-domain.com | grep -i "samesite=none" | grep -iv "partitioned"

# 2. Test in Safari (use Safari or WebKit simulator)
# Cross-site cookie failures are silent — check Application tab in DevTools

# 3. Check for missing Secure flag (required with SameSite=None)
# SameSite=None without Secure is rejected by all modern browsers

# 4. Automated audit:
# httpfixer.dev/cookies/ — paste your URL, get flagged cookies + fix per stack