Chrome cookies not saving — where you log into a site, close the tab, reopen it, and have to log in again — is the kind of problem that starts as a minor annoyance and turns into a significant time sink. Most causes are in Chrome’s settings, not the sites themselves. For the bigger picture, our Google Chrome Errors pulls everything together.
The single fastest check: visit chrome://settings/content/cookies and look at the first setting — “Allow sites to save and read cookie data.” Is it on? If it’s off, that’s the entire problem. Toggle it on. Done. If it was already on, keep reading.
Also check immediately below: is the site you’re having trouble with in the “Not allowed to use cookies” list? If it is, remove it from that list and try again.
The “clear cookies when you close Chrome” trap
This is the most common cause that people set once and forget about. Settings → Privacy and security → Cookies and other site data → scroll down to find “Clear cookies and site data when you close all windows.” If this is On: cookies delete automatically every time Chrome closes. That’s why you’re logged out every session. Toggle it off.
If you want to keep this setting for general privacy but need specific sites to stay logged in: add those sites to the “Customised behaviours” exception list → click “Add” next to “Sites that can always use cookies” → enter the domain. Those sites keep cookies permanently while everything else clears on close.
Chrome cookie settings — the full picture
chrome://settings/content/cookies has several settings that interact with each other. Worth reviewing the full page:
- Third-party cookies: blocking these affects sites that use third-party authentication (Google Sign-In, Facebook Login on other sites). If you log in via a third-party provider and cookies don’t persist: temporarily enabling third-party cookies for that site tests whether this is the cause.
- Default behaviour: should be “Sites can save and read cookie data” — the alternative breaks most modern websites.
Extensions blocking cookie saving
Privacy extensions (Privacy Badger, Cookie AutoDelete, uBlock Origin in strict mode) actively delete or block cookies. Some do it immediately, some on a timer, some when the tab closes. The behavior varies by extension and configuration.
The same settings and extensions that wipe cookies often wipe browsing data too — if you also find that Chrome is not saving history, the cause usually traces back to the same on-exit or privacy configuration.
Open an Incognito window — Ctrl+Shift+N. Extensions are off by default. Log into the problematic site in Incognito and close the window (or close and reopen the tab). If the cookie persists in Incognito: an extension is clearing cookies in regular Chrome. Disable extensions one at a time in chrome://extensions to find the culprit.
Cookie AutoDelete is particularly worth checking — it’s specifically designed to do exactly what the symptom describes. Check its allowlist and add sites you want to stay logged into.
Site-specific issue: the site’s own cookie settings
Some websites set their cookies with attributes that prevent persistence: session-only cookies that expire when the browser closes, or cookies with very short expiry times. This is the website’s decision, not a Chrome setting. Nothing on the Chrome side can override a cookie the website intentionally set to expire on session end.
The only indication: other sites work fine, this specific site never keeps you logged in across sessions, and the Incognito test doesn’t help (it also fails). If it logs you out on every browser, every device, it’s the website’s design.
Corrupted cookie database
Chrome stores cookies in a SQLite database. When this file becomes corrupted — from a system crash, a failed Chrome update, or a disk error — cookies write but don’t persist correctly between sessions.
Close Chrome → navigate to %localappdata%GoogleChromeUser DataDefault → find the “Cookies” file → rename it to “Cookies.old” → reopen Chrome. Chrome creates a fresh database. You’ll need to log into all sites again, but the database is clean. The old file stays as Cookies.old until you’re confident everything is working, then delete it.
Guest mode and Incognito: intentionally no persistence
Cookies never persist in Incognito or Guest mode — that’s by design. If Chrome is launching in one of these modes by default (check the title bar for “Incognito” or “Guest”), no cookie saving will work regardless of settings.
Chrome profile sync issues
If cookies were previously saving and stopped: Chrome sync changes sometimes affect how local data is treated. Sign out of Chrome completely → sign back in → check whether cookie saving resumes. In some cases a sync anomaly causes Chrome to treat all browsing as a different profile state where session data doesn’t persist normally.
Our guide on Chrome sync problems covers the sync-related profile state issues. For the privacy extension conflicts, our Chrome loading issues guide covers the extension diagnostic approach in more detail. Google’s Chrome privacy settings documentation covers the full cookie permission hierarchy, including how enterprise policies override user settings for cookie handling.
Third-party cookie phase-out and login implications
Google has been progressively limiting third-party cookies across Chrome versions. Sites that relied on third-party cookies for their “stay logged in” functionality — particularly single sign-on implementations that use cross-site cookies — break when these cookies are blocked. A site that used to remember you may stop doing so after a Chrome update even though nothing changed in your settings, because the site relied on third-party cookies that Chrome now blocks by default.
Chrome shows a notification icon when third-party cookies are blocked on a site. If you see a cookie icon in the address bar: click it → manage permissions for that site → allow third-party cookies for that specific domain. This is more targeted than enabling third-party cookies globally.
Partitioned cookies (CHIPS) behaviour
Newer Chrome versions implement cookie partitioning — cookies set in iframes or embedded contexts are partitioned by the top-level site. This prevents a third-party embedded on multiple sites from tracking your activity across those sites. It also means some authentication tokens that were previously shared across sites no longer work as expected, causing logout loops that look like cookies aren’t saving.
This is increasingly common on corporate SSO (Single Sign-On) implementations that embed authentication in iframes across multiple subdomains. IT administrators can add the relevant domains to the enterprise exceptions list. Individual users can try: chrome://flags/#cookie-deprecation-facilitated-testing → check this isn’t interfering. This is an evolving area — Chrome’s Privacy Sandbox documentation covers the current state for developers.
Windows Disk Cleanup and cookie loss
Windows Disk Cleanup has an option to clear browser data. If “Temporary Internet Files and Pages” was included in a recent Disk Cleanup run, it may have cleared Chrome cookies despite the ambiguous description. Check Event Viewer → System → around the time cookies disappeared for any Disk Cleanup activity.
More commonly: antivirus software with browser data cleanup features does this automatically on a schedule. Kaspersky, Norton, McAfee, and ESET all include browser cleaner modules that can be configured to clear cookies at specific intervals. Check the antivirus settings for any browser cleanup configuration and disable or exempt the specific sites from cookie clearing.
Chrome’s site settings override hierarchy
Cookie settings apply in a specific priority order: enterprise policy (highest) → individual site permissions → third-party cookie settings → default. If a setting appears correct at one level but cookies still don’t save: a higher-priority setting is overriding it.
Check enterprise policy override: navigate to chrome://policy/. If “CookiesAllowedForUrls” or “DefaultCookiesSetting” appear with values restricting cookies, these are enterprise-controlled and cannot be overridden from Chrome settings. On personal machines this is uncommon; on corporate managed machines it’s relatively frequent.
Storage quota and disk space
Chrome respects a storage quota for cookies and site data. On machines with very little free disk space (under 1–2 GB), Chrome may refuse to write new cookie data. Settings → Privacy and security → Site settings → Cookies and site data → “Usage” — if this shows a very large number of cookies, clearing unused cookies makes room for new ones.
Also check: Settings → System → Storage → C: drive free space. Under 5 GB is problematic for Chrome generally. Disk Cleanup before retrying cookie-dependent sites sometimes resolves storage-quota-related saving failures.
Cookies saved but not being sent
A different problem that looks similar: cookies are saving (you can verify this at chrome://settings/content/cookies → “See all cookies and site data” → search for the site’s domain) but the site doesn’t receive them on subsequent visits. This happens when the cookie has a Secure flag but the site is loading over HTTP instead of HTTPS, or when the SameSite attribute prevents the cookie from being sent in certain contexts.
Verify the site is loading over HTTPS (padlock icon in address bar). If the site loads over HTTP and the cookie has a Secure flag: the browser correctly refuses to send the cookie over an insecure connection. The fix is the site switching to HTTPS — there’s no client-side workaround for this because the browser’s behaviour is correct.
Cookie viewer for diagnosis
To confirm whether a cookie is actually being saved (rather than guessing): Log into the site → F12 (DevTools) → Application tab → Cookies → click the site domain. All cookies for that site appear with their name, value, domain, expiry date, and attributes (Secure, HttpOnly, SameSite). The Expires/Max-Age column immediately shows whether the cookie is a session cookie (no expiry date = deleted on browser close) or a persistent cookie (specific expiry date = stored between sessions). If the cookie shows “Session” in the Expires column: the website sets it as session-only, and nothing Chrome-side can change that to persistent.
Multiple Chrome profiles and cookie isolation
Each Chrome profile has completely separate cookie storage. Cookies saved while signed into Profile A don’t exist in Profile B. If the “wrong” profile opens when clicking a browser shortcut or link, you’ll always be logged out — because the cookies were saved to a different profile.
Check the profile icon in the top right of Chrome’s window. If it shows the wrong profile name or a generic “Person 1” label: switch to the correct profile where the cookies were originally saved. Pin the correct profile’s window to your taskbar so links open in the right profile by default.
Regularly cleared browsing data schedule
Settings → Privacy and security → Delete browsing data → look at the “Basic” tab’s settings. If “Cookies and other site data” is checked with time range “All time” and this was recently run: all cookies were deleted. More importantly: check whether Chrome has a scheduled data clear configured. Some Chrome versions and extensions allow scheduled clearing — if this runs overnight, cookies appear to “vanish” without any obvious trigger.
For persistent protection: add important sites to the “Always clear” exception list’s inverse — the “Sites that can always use cookies” list in chrome://settings/content/cookies. Sites on this list have their cookies protected from Chrome’s built-in clearing, third-party blockers, and most extension clearing operations.
The DevTools cookie viewer is worth bookmarking mentally as a diagnostic tool for any future cookie problem: F12 → Application → Cookies → click the domain. This shows the exact state of every cookie for the site at that moment — whether they exist, when they expire, and what attributes prevent them from being sent. Five seconds in DevTools often answers “why am I still logged out” more definitively than any settings investigation.
To summarise the most likely causes in order of frequency: “clear cookies on close” setting is enabled → check first. Extension clearing cookies (especially Cookie AutoDelete) → test in Incognito. Site sets session-only cookies → nothing Chrome-side can fix this. Corrupted cookie database → rename and regenerate. Each subsequent cause is progressively less common — most “Chrome not saving cookies” reports resolve at the first or second point in this list.
SameSite=Strict cookies and navigation
Cookies with the SameSite=Strict attribute are only sent when navigating from the same site — not when arriving from a different site via link, redirect, or bookmark. This is a security feature to prevent CSRF attacks. The practical result: you click a link to a site from email or another website, arrive at the site, and appear logged out — even though the cookie exists. The cookie is there; it just wasn’t sent for this navigation type.
Navigate directly (type the URL or use a bookmark from the address bar) rather than clicking external links. If you’re logged in on a page and navigate away and back, the cookie is sent correctly. SameSite=Strict cookies are a website security decision and correct browser behaviour — not something to change in Chrome settings.
HTTPS-only mode
Chrome’s HTTPS-only mode (Settings → Privacy and security → Security → Always use secure connections) prevents loading HTTP pages. If a site sets cookies on an HTTP page and HTTPS-only mode blocks that page: the cookies never get set in the first place, causing what appears to be a cookie-saving failure when it’s actually a page-loading failure. Check whether the problematic site loads correctly — if it shows a “Not Secure” upgrade prompt, HTTPS-only mode is intercepting it.
Add an exception for the specific site: Settings → Security → “Not secure sites that can show this” → add the domain. This allows the site to load over HTTP where needed for cookie-setting pages while maintaining HTTPS-only for all other browsing. You might also run into Chrome Tab Keeps Crashing.
