Chrome cookies not working — sites forgetting you’re logged in between visits, “please enable cookies” warnings on sites that already have them on, shopping carts dropping items, or specific sites blocked from setting cookies entirely — usually traces back to one of three settings or a privacy extension being too aggressive. This fits into the wider topic we cover in our Google Chrome Errors.
The quickest single test: try the failing site in Incognito (Ctrl+Shift+N). Incognito accepts cookies for that session and discards them at the end. If the site works in Incognito but not in normal browsing: your regular Chrome has either site-specific cookies blocked, an extension interfering, or third-party cookies disabled for a site that needs them. If it fails in Incognito too: the issue is the site itself or your network’s policies.
Chrome’s cookie settings — where most fixes live
Type chrome://settings/cookies in the address bar. This page controls Chrome’s cookie behaviour at three levels:
“Block third-party cookies”: the most common culprit for sites breaking. Third-party cookies are what cross-site tracking uses, but they’re also what many legitimate site integrations rely on — login systems that span multiple domains, embedded payment processors, shopping cart sync across regions. If this is set to “Block third-party cookies in Incognito mode” but a site is failing in normal mode: that’s not the issue. If it’s set to “Block third-party cookies in all modes,” sites needing cross-domain cookies will fail.
Specific site exceptions: scroll down on the same page. “Sites that can always use cookies” and “Sites that can never use cookies” lists. If a problem site is in the “never” list, that’s your answer — remove it. If a site you trust isn’t in the “always” list and third-party cookies are blocked, add it.
“Clear cookies and site data when you close all windows”: this nukes all cookies on every Chrome close. Convenient for privacy but means every site forgets you between sessions. Toggle it off if you don’t want this aggressive behaviour.
Clear cookies for the specific failing site
A corrupted cookie for one site causes all sorts of weird login and session issues. Fixing it is more surgical than clearing everything:
- Visit the failing site → click the lock icon (or 🔒 / “View site information”) to the left of the URL
- Click “Cookies and site data”
- “Delete data” button
- Reload the site → sign in fresh
You’ll need to log in again afterward, but session state is rebuilt cleanly. This resolves cases where the cached cookie has an expired or corrupted token that the site can’t recover from gracefully.
Extensions blocking cookies invisibly
Privacy and ad-blocking extensions filter cookies even when Chrome’s settings would normally allow them. uBlock Origin in particular can block cookies via filter lists you didn’t explicitly configure. Privacy Badger blocks tracking cookies aggressively. Ghostery, EFF Privacy Badger, and Cookie AutoDelete all have their own cookie management that overrides Chrome’s.
Quick diagnostic: chrome://extensions → toggle off all extensions → revisit the failing site. If cookies suddenly work: an extension is the cause. Re-enable one at a time to find which.
Once identified: most privacy extensions have a per-site whitelist where you can allow cookies for trusted sites without disabling protection elsewhere. uBlock Origin: click the icon on the failing site → toggle the big power button “off for this site.” Privacy Badger: click the icon → adjust the slider to “Allow” for the failing domain.
SameSite cookie strictness
Modern Chrome strictly enforces SameSite cookie attributes for security. Sites that haven’t updated their cookie configuration may have broken cross-domain login flows. Symptom: redirect-based login (SSO between work apps, OAuth flows through Google or Microsoft) gets stuck in a loop or fails immediately.
Workaround for testing: chrome://flags → search “SameSite” → there’s a flag called “SameSite by default cookies” that controls strictness → set to Disabled → restart Chrome → test. If the site works now: it’s a SameSite-related bug at the site’s end. They need to fix their cookie configuration (add SameSite=None; Secure attributes to cookies that need to work cross-domain).
Don’t leave this flag disabled permanently — it lowers your security posture for the convenience of one broken site. Better to report the issue to the site’s support.
Our guide on Chrome page loading issues covers the broader connectivity problems that sometimes manifest as cookie failures, and our Chrome crash troubleshooting covers issues that prevent cookies from being saved properly. For detailed cookie policy and security configuration, Google’s Chrome support documentation covers the cookie settings page and the new third-party cookie phase-out roadmap.
Third-party cookie phase-out reality check
Google has been gradually phasing out third-party cookies since 2024, with full deprecation happening in stages. As of 2026, many third-party cookies are blocked by default, and sites that haven’t migrated their login flows to alternatives (like Storage Access API or first-party authentication) will fail in subtle ways.
You can’t reverse this trend at the browser level — it’s intentional. What you can do: enable third-party cookies on specific sites you trust. chrome://settings/cookies → “Allowed to use third-party cookies” → “Add” → enter the domain. The site can then set third-party cookies despite the global block.
For sites that absolutely refuse to work: Firefox or Edge sometimes have slightly different cookie behaviour. Not a fix, but a workaround if a specific business-critical site is broken in Chrome.
“This site needs cookies enabled” but they look enabled
Bewildering when it happens. You check Chrome settings, cookies are enabled globally, site-specific allow list looks fine, but the site insists you’ve blocked cookies. Common causes:
- The site needs both cookies and localStorage; you’ve allowed cookies but blocked storage (Chrome groups these together but they’re separately checked by some sites)
- Browser tracking protection (chrome://settings/privacy → “Privacy and security”) is blocking the specific tracking cookies the site uses for session state
- The site is detecting Incognito mode (some sites do this and refuse to work even if Incognito is technically allowing cookies)
- An extension is silently blocking the cookie before Chrome’s logic even sees it
Run through the diagnostic: chrome://settings/privacy → make sure “Standard” protection is selected (not “Enhanced”) → reload site. Standard mode allows most legitimate cookies; Enhanced blocks more aggressively.
Network-level cookie blocking
Some corporate networks block specific cookie types at the proxy or firewall level. Cookies are passed via HTTP headers; corporate security tools can strip or modify these. Symptoms: cookies work at home but not at work for the same sites, with no client-side changes.
If you suspect this: open Chrome’s DevTools (F12) → Application tab → Cookies → visit the failing site. If cookies aren’t being set at all (the list stays empty), they’re being stripped before they reach the browser. If they’re set but then disappear on the next request: they’re being filtered on outbound. Either way, this is IT’s responsibility to investigate, not yours.
Cookies and Chrome Sync
Chrome Sync syncs many things across devices: bookmarks, passwords, extensions, history. By default, cookies are NOT synced — they’re per-device. If you logged in on Chrome at home and the same site asks for login at work, that’s expected behaviour. Some users mistake this for “cookies not working” when really it’s just how Chrome Sync is designed.
You can’t enable cookie sync without specific business configurations. The intended workflow is: log in to your Google account on Chrome at both devices → password manager fills in the saved password automatically → site logs you back in. Cookies stay device-specific for privacy reasons.
Profile corruption affecting cookie storage
If cookies disappear randomly between sessions, or sites that worked yesterday demand login again: your Chrome profile’s cookie database might be corrupted.
Test with a fresh profile: Chrome → profile icon → Add → continue without account → visit a site, log in, close, reopen → does the login persist? If yes, your original profile is the issue. Either start using the new profile permanently (with Chrome Sync to restore bookmarks/passwords), or fix the old one with chrome://settings/reset.
| Issue | Most likely cause | Fix |
| Site forgets login every visit | Cookies blocked or auto-delete on close | Disable “Clear cookies on exit”; check site exceptions |
| “Enable cookies” warning despite settings | Extension blocking or tracking protection | Test in Incognito; check extensions; lower protection level |
| Login loop / SSO breaks | SameSite enforcement or third-party blocked | Allow third-party cookies for trusted sites |
| Cart drops items between visits | Site cookies expiring or being cleared | Add site to cookie exceptions allow list |
| Cookies work at home, not work | Network-level filtering | IT investigation; check DevTools for stripped headers |
| Random cookie loss across browsers | Profile corruption | Test in fresh profile; reset Chrome if confirmed |
For everyday cookie problems, the diagnostic flow is: Incognito test → check site-specific exceptions → check extensions → check third-party setting. Most cases resolve at one of those four checkpoints. The deeper scenarios (SameSite, corporate proxies, profile corruption) only matter for specific environments.
Cookie database location and manual reset
If you want to nuke the cookie database entirely without affecting other browser data: close Chrome completely (check Task Manager for residual processes) → navigate to %localappdata%GoogleChromeUser DataDefault → find the file called “Cookies” (no extension) → delete it. Reopen Chrome. A fresh empty cookie database is created on launch.
You’ll need to log in to everything again. But this resolves cases where the database itself has corruption that Chrome’s standard “clear cookies” UI doesn’t fix (a real, if uncommon, issue).
Same idea for sync state: if Chrome Sync is misbehaving and cookies aren’t being applied correctly, signing out of Chrome (profile icon → menu → “Pause” or “Sign out”) and signing back in re-establishes the sync session cleanly.
Saved passwords and cookie interaction
Saved passwords in Chrome work alongside cookies but separately. If a site’s cookie expires, Chrome’s saved password lets you log back in instantly — the password autofills, you click sign in, the site sets a fresh cookie. This is the intended graceful fallback.
If saved passwords aren’t autofilling: that’s a separate issue from cookies, but worth checking. chrome://settings/passwords → confirm the credential is stored for the site → “Offer to save passwords” is enabled. Once both cookies and password manager work together, login persistence is essentially seamless even with aggressive cookie clearing.
Mobile vs desktop cookie behaviour
Chrome on Android and Chrome on Windows have slightly different default cookie behaviours, especially around third-party cookies and tracking protection. If a site works on your phone’s Chrome but not on desktop Chrome (or vice versa): the protections differ between platforms.
Both platforms have moved aggressively against third-party cookies; the timing of changes varies. If a site explicitly recommends specific browser settings, follow them — different platforms expose the relevant settings in different places.
For users who frequently switch between mobile and desktop: keeping Chrome Sync on and trusting password manager autofill means login persistence is more about the autofill working than about cookies surviving exactly the same on each platform.
Cookie banners and consent management
The endless “Accept cookies” banners on EU and California-targeted sites aren’t a Chrome issue, but they affect cookie behaviour in ways users sometimes confuse with “cookies not working.” If you keep clicking “Reject all” on a site’s cookie banner, the site stores a preference cookie (ironically) and may also refuse to set the cookies it needs for full functionality.
For sites where you want everything to work: click “Accept” on the consent banner once. For sites you don’t trust: click “Reject” and accept the degraded experience. Extensions like “I don’t care about cookies” auto-accept consent banners — useful for reducing the friction but ethically debatable; you’re consenting on autopilot to tracking you might not want.
Realistically, what most users want is functional logins and shopping carts on sites they actually use, with tracking blocked at the browser level (uBlock Origin etc.) rather than negotiated banner-by-banner. That’s the pragmatic middle ground.
When all else fails — the nuclear option
If you’ve tried every targeted fix and cookies are still broken, full Chrome reset is the last step before reinstalling:
- chrome://settings/reset → “Restore settings to their original defaults”
- This disables extensions, clears site permissions, resets cookie settings — but keeps bookmarks and saved passwords
- Test cookies after reset
If even this doesn’t work: Chrome installation itself is corrupted. Uninstall via Settings → Apps → Chrome → Uninstall. Manually delete %localappdata%GoogleChrome → reinstall from chrome.com. This is rarely needed but exists as the last resort.
Most cookie issues, fortunately, never reach this point. The chrome://settings/cookies page, combined with a one-minute Incognito test and an extensions check, handles the great majority of “Chrome cookies aren’t working” reports — usually in under 5 minutes total once you know where to look. If this sounds familiar, Chrome Downloads Not Working is worth a look.
