Delete cookies for a specific site in Chrome without signing out everywhere

A single service is misbehaving. A dashboard shows a stale account, a form refuses to submit, a support agent has said to clear cookies and try again. The tool that everyone reaches for is the big one: Delete browsing data, All time, Cookies and other site data. It works, and it also signs the browser out of every other service at the same time, which on a working machine can mean a dozen logins and several rounds of two-factor codes to get back to where the day started.

Chrome has a narrower instrument for exactly this. It removes one site's data and leaves everything else untouched. It is three clicks deeper in Settings than the blunt version, which is the only reason it is less well known.

What the blunt version actually takes with it

Google's own warning on the wide delete is worth reading before choosing between the two routes:

Important: If you delete cookies, you may get signed out of sites that remember you. Your saved preferences can also be deleted. This applies whenever a cookie is deleted. Source: support.google.com

The last sentence is the part that catches people. Saved preferences are not a separate category that survives. A cookie is where a great deal of small state lives: which theme a service is set to, which timezone it assumes, which of several accounts is the active one, whether a tour has been dismissed, which filters a queue was left on. All of it goes when the cookie goes.

That is acceptable for one site that is already broken. It is a bad trade across forty sites that were working. The cost is also asymmetric in a way that is easy to underestimate: the services that are most annoying to sign back into, the ones with hardware keys or short session timeouts, are exactly the ones that were not causing the problem.

Choosing the narrow route is not about being careful. It is about not paying for a fix on sites that did not need one.

The route that removes one site and nothing else

The path runs through the third-party cookies section, which is a slightly odd place for it, and that is why people miss it. Google documents the sequence as opening Settings, then Privacy and security, then Third-party cookies, then See all site data and permissions, searching for the site's name at the top right, and selecting Delete to the right of the site, then confirming.

Two details make it work faster in practice. The search field matches on the site name, so typing a fragment is enough, and entries are grouped by site rather than listed as individual cookies, so there is nothing to pick through. The Delete action on a row takes that site's stored data with it rather than only the cookie, which is usually what was wanted anyway, since a broken app state is as likely to be sitting in local storage as in a cookie.

The faster route from the address bar

For the site currently open, there is a shorter path. Selecting the site information control at the left of the address bar, then Cookies and site data, then Manage on-device site data, opens the same data for that one origin without going through Settings at all. Google's documentation mentions this route in the context of finding related sites, and it is the one worth learning, because it takes the site being fixed as its input instead of requiring its name to be typed.

One reflex is worth adding here. After deleting, reload with the page's own reload rather than reopening the tab from history, and expect to sign in again on that site alone. If the symptom survives a fresh sign-in, the state that caused it was never local, and no amount of further deleting will help.

Why the per-site list sits under Third-party cookies

The placement looks like a filing mistake and is not. Chrome distinguishes two kinds of cookie by who created them, and the distinction decides which screen a given repair belongs on.

First-party cookies are created by the site in the address bar. Third-party cookies are created by other sites whose content is embedded in the page, which Google's documentation lists as images, ads, and text, and which in practice also covers an editor, a chat widget, a payment field, or a support console dropped into someone else's app. Those embedded pieces can read what they saved about a visitor across the different sites they appear on, which is why they get a settings page of their own.

The per-site data list ended up there because both kinds of data for a site are shown in one place, and the third-party screen is where the exceptions that govern them already lived. Once the list is open, that history does not matter. What matters is that a single row can hold state written by the site and state written by whatever it embeds.

This also explains a failure that looks like the delete did not work. Clearing one site's data does nothing to an embedded service's own origin, so if the broken piece is a widget rather than the page around it, the state that needs clearing belongs to the widget's site. The list can be searched for that site directly.

Two further controls sit on the same screen and are worth recognising. When third-party cookies are blocked, a separate switch governs whether sites that a company has declared as related may still see activity within that group, and Google publishes that the full list of companies defining such groups is on GitHub. In the site data list, a drop-down arrow on a row reveals the other sites in the same group. For anyone trying to work out why a sign-in survives across what look like unrelated domains, that arrow answers the question faster than any amount of deleting.

What this does not clear

The narrow delete is scoped to one site's stored data, which means several nearby things are untouched, and knowing which ones prevents a second round of guessing.

Saved passwords are separate and stay, which is what makes the narrow route survivable: the sign-in that follows is a form fill rather than a password reset. Extensions and their settings are separate and stay. Anything held by another site is untouched by definition, which is the whole point, and that includes a third party embedded in the page being fixed. If a widget inside the app is the thing that is broken, its data belongs to its own origin.

Route	Scope	Signs you out of
Delete browsing data, Cookies and other site data	Every site, over the chosen time range	Everything that remembered you
See all site data and permissions, Delete on one row	One site's stored data	That one site
Site information, Manage on-device site data	The site currently open	That one site
A separate browser profile	Everything inside that profile only	Only what was signed in there

The last row is the one people arrive at after doing this a few times, and it is a different kind of answer. It does not clean anything. It limits how much a future clean can cost.

Timing is worth one note as well. The wide route asks for a time range, from the last hour to all time, and the narrow route does not. A per-site delete is always complete for that site, so there is no way to remove only today's state and keep last week's. That is usually fine, because a stale session is not a dated problem, but it does mean the narrow route cannot be used as a gentle version of itself.

Settings that reduce how often this comes up

Three settings shorten the cycle, and all three are documented rather than folklore.

On-device site data has a default behaviour with three options: allow sites to save data, delete what sites saved when all windows are closed, or do not allow it at all. Google's description is candid about the trade, noting that the middle option means sites will probably work as expected but are less likely to remember anything from one visit to the next. Set per site rather than globally, it is a good fit for a service that reliably goes stale.

Exceptions accept a wildcard form. Entering [*.]google.com covers subdomains, so one entry can cover an app spread across several hostnames rather than needing an entry for each. Google's documentation also notes that an IP address is accepted, which matters for an internal tool reached without a hostname.

Temporary allowances expire on their own. When third-party cookies are allowed for a site from the address bar in normal browsing, Google documents that the site is added to the exceptions list for 90 days or until the setting is turned off. Related sites granted permission through an in-page prompt are documented as lasting 30 days or as long as activity continues. Both are worth knowing, because a service that worked last quarter and stopped this quarter may simply have reached the end of a window rather than changed.

Why this keeps happening in the first place

Step back from the mechanics and the pattern is structural rather than accidental. One browser profile holds one cookie jar. Every service in it shares that jar, so any repair scoped to the jar is either too narrow to reach the problem or too wide to be free. The narrow delete is a good tool for the specific case, and it does not change the arrangement that produced the case.

The arrangement changes when each service gets its own store. Running one web app per container means the cookies for a ticket queue are not in the same place as the cookies for a mail account, and clearing one is physically incapable of touching the other. It also settles the adjacent problem, which is two accounts of the same service, since a per-app store lets both stay signed in at once. That separation is what the Workspaces page describes, the list of services that behave well in a separate container is on the Supported apps page, and Compared with Rambox sets out how the tools in that category differ.

Nothing about that removes the need for the narrow delete. It changes the blast radius when a delete is needed, from every service on the machine to one.

What to change first

Learn the address bar route, since it is the one that applies when something is already broken: site information, Cookies and site data, Manage on-device site data. Then check whether the service that keeps going stale would be better served by the on-device site data option that clears when all windows close. If two or three services get cleared regularly, giving each one its own container, as SpaceDeck does, stops the next clear from reaching the others.