Clear cookies but stay logged in

TL;DR: To clear cookies without logging out of trusted sites, whitelist those domains in a Manifest V3 cookie manager first, then delete everything else. CookieVault Guardian makes this a two-click operation; Chrome’s built-in tool requires manually preserving each site.

Clearing cookies but staying logged in is a selective deletion workflow that removes tracking and analytics cookies while preserving session cookies for domains you trust. The standard “clear all cookies” approach logs you out of every site indiscriminately — banking, email, project tools, everything. Selective deletion solves this by drawing a line between cookies you want (authentication sessions) and cookies you do not (third-party trackers, analytics identifiers, ad-network pixels). Chrome does not offer a built-in whitelist for this purpose, but a Manifest V3 extension fills the gap¹.

Why selective deletion matters

In short: The average browsing session accumulates cookies from dozens of third-party domains. Deleting all of them wipes your logins; deleting none of them lets trackers persist. Selective deletion is the middle path — clean the trackers, keep the sessions.

A 2024 study by the University of Iowa and UC Davis analyzing over 80,000 websites found that the median site sets 20 cookies, with the top 10% setting more than 60, most of which originate from third-party advertising and analytics domains². That proliferation means a “clear all” operation destroys far more session state than most users intend.

The selective approach works because authentication cookies and tracking cookies live on different domains. Your Gmail session cookie sits on accounts.google.com; the tracking pixel that followed you from a shoe ad sits on doubleclick.net. By whitelisting accounts.google.com and deleting doubleclick.net, you stay logged in to Gmail while removing the tracker.

Key reasons to adopt selective deletion:

• Preserve active sessions for email, banking, and work tools
• Remove cross-site tracking cookies that follow you across domains
• Reduce your browser’s cookie jar size, which can improve page load performance
• Comply with personal privacy standards without the inconvenience of re-authenticating everywhere
• Maintain shopping carts and draft states on trusted e-commerce sites
• Avoid breaking federated login flows that depend on third-party identity providers

Comparison: selective deletion methods in Chrome

In short: Chrome Settings lets you delete per-site but has no whitelist. DevTools gives per-cookie precision but requires manual work per domain. A Manifest V3 extension is the only option that combines a whitelist with bulk cleanup.

Chrome’s built-in privacy controls were designed for “clear everything” scenarios. As the Chrome DevTools documentation notes, the Application panel’s cookie view is intended for inspection and debugging, not for routine privacy maintenance¹. Extensions exist precisely to fill this workflow gap.

Method 1: CookieVault Guardian (recommended)

In short: Guardian’s whitelist-and-clean workflow takes two clicks after initial setup. Add your protected domains once; every future cleanup preserves them automatically. Auto-clean on tab close makes it fully hands-free.

The eight-step selective deletion workflow with CookieVault Guardian:

1. Identify protected sites — list every domain where losing your session would be disruptive: email providers, banking portals, project management tools, cloud storage, social accounts you use daily.
2. Open DevTools on a protected site — press F12 → Application → Cookies to see the exact cookie names (SID, SSID, PHPSESSID, jsessionid, _session_id). This confirms which domain holds the session cookie — sometimes it is a subdomain or a federated identity domain, not the site’s main domain.
3. Install CookieVault Guardian — install from the Chrome Web Store. Guardian is a Manifest V3 extension that uses the chrome.cookies API for privileged access to HttpOnly cookies that JavaScript cannot touch.
4. Add protected domains to the whitelist — open Guardian → Settings → Whitelist. Paste domains one per line, or visit each site and click “Whitelist current site” in the toolbar popup.
5. Review the cookie inventory — open the Guardian dashboard. Non-whitelisted cookies from ad networks, analytics providers, and tracking pixels are listed with a red indicator. Whitelisted cookies show a shield icon.
6. Run selective cleanup — click “Clean up now.” Guardian deletes every cookie not belonging to a whitelisted domain. If “Full site data cleanup” is enabled, localStorage, IndexedDB, and Cache Storage for non-whitelisted origins are also cleared.
7. Verify protected sessions — open each protected site in a new tab. You should still be logged in. If a site logged you out unexpectedly, its authentication depends on a cookie from a different domain — add that domain to the whitelist.
8. Schedule recurring cleanup — enable “Auto-clean on tab close” or set a timed interval (daily, every 12 hours). This keeps your cookie jar clean without manual intervention.

Method 2: Chrome Settings (manual)

In short: Chrome Settings lets you delete cookies per site, but there is no whitelist. You must manually search for and skip each protected domain. This method works for one-off cleanups but does not scale.

The manual workflow through Chrome’s built-in UI:

1. Open Chrome Settings (chrome://settings) → Privacy and security → Cookies and other site data
2. Click “See all cookies and site data” — Chrome shows an alphabetical list of every domain with stored data
3. Use the search box to find a tracking domain (e.g., doubleclick.net)
4. Click the trash icon next to it — Chrome deletes all cookies and site data for that origin
5. Repeat for every tracking domain you want to remove
6. Do not click “Remove all” — that deletes everything, including your protected sessions
7. For a faster bulk approach, use Ctrl+Shift+Delete → select “Cookies and other site data” → choose a time range — but this is all-or-nothing within that range
8. Verify your protected sessions by visiting each important site

The manual method’s main limitation is that it requires you to know which domains to delete and which to skip. Most users cannot identify every third-party tracker by domain name, which is why a whitelist-based tool is more practical for regular use.

Common session cookie names to protect

In short: Most web frameworks use predictable session cookie names. Knowing them helps you verify that your whitelist is protecting the right cookies.

When reviewing your cookie inventory before cleanup, look for these common session identifiers on your protected domains:

• SID, SSID, HSID, APISID — Google services (Gmail, YouTube, Drive, Calendar)
• PHPSESSID — PHP-based sites (WordPress, Magento, many custom apps)
• jsessionid or JSESSIONID — Java-based enterprise apps (Jira, Confluence, Jenkins)
• _session_id — Ruby on Rails applications (GitHub, Shopify admin, Basecamp)
• connect.sid — Node.js Express applications
• ASP.NET_SessionId — .NET-based sites (Azure DevOps, many corporate portals)
• csrftoken + sessionid — Django applications
• laravel_session — Laravel (PHP) applications

If a site uses federated login (Sign in with Google, Sign in with Apple), the session cookie may live on the identity provider’s domain rather than the site itself. For example, signing in to a site via Google requires cookies from accounts.google.com — whitelist both the site and the identity provider.

What happens if you accidentally clear a protected cookie

In short: Losing a session cookie logs you out but does not delete your account data. Re-authenticate to get a fresh session cookie. If you exported your cookies first, you can re-import them to restore the session without re-authenticating.

Six things that happen when you accidentally delete a session cookie:

• The next request to that site arrives without a session identifier
• The server treats you as a new, unauthenticated visitor
• You see a login page or a “session expired” message
• Re-authenticating creates a fresh session cookie — your account data, settings, and history are intact on the server
• If you had an active form draft or unsaved work in a web app, it may be lost (depends on whether the app uses localStorage or server-side autosave)
• Two-factor authentication may be required again if the site’s “remember this device” was stored as a separate cookie you also deleted

The safest approach is to export cookies before any bulk deletion. CookieVault Editor’s JSON export gives you a restore path — import the file to reinstate session cookies without re-typing passwords. See our guide on exporting cookies to JSON for the full workflow.

See also

• How to delete cookies in Chrome — the full deletion guide when you want to wipe everything
• How to whitelist cookies in Chrome — detailed whitelist configuration for Chrome Settings and extensions
• Auto-delete cookies on tab close — the automated version of selective deletion
• How to export Chrome cookies to JSON — backup sessions before clearing
• CookieVault Editor — the open-source Manifest V3 cookie manager for viewing, editing, and exporting cookies
• CookieVault Guardian — the automated cleanup extension with whitelist support