Chrome Account Switch Not Working: Which Switcher Failed

The picture is always slightly different. Sometimes the account list opens and the right name is there, but selecting it changes nothing. Sometimes the list is short and the account that should be in it never appears. Sometimes everything looks correct until a link arrives in a chat message, opens in a fresh tab, and lands on the wrong identity again. The common thread is that the switch appears to happen and the result does not follow.

Most of the time nothing is broken. There are two separate switchers sitting in almost the same place at the top right of a Chrome window, they change different things, and a lot of the confusion comes from pulling the wrong one.

Two switchers, one corner of the window

The first is the Chrome profile switcher. A profile is a storage area on the Mac that holds its own cookies, saved passwords, history, bookmarks, extensions and settings. Switching profiles opens a different window backed by a different storage area. Nothing carries across. If a site is logged in under one profile, the other profile sees a logged out site.

The second is the Google account switcher, which lives inside Google's own web pages rather than in the browser chrome. It appears on Gmail, Drive, Calendar and the rest as a round avatar in the page itself. That switcher moves between accounts that are already signed in to the current storage area. It does not create a new storage area and it does not isolate anything.

Two consequences follow from that difference, and they explain a large share of the reports.

• Switching the Google account never separates cookies. Both accounts remain signed in to the same profile, and every site that reads that profile sees both.
• Switching the Chrome profile always separates cookies. The other profile has no idea the first account exists, which is exactly why a freshly created profile shows an empty account list.

When a reader says the switch is not working, the useful first question is which of the two was used and what result was expected. Wanting isolation and reaching for the in-page avatar produces a switch that appears to do nothing, because the thing that needed to change was never touched.

A quick way to tell them apart

The profile switcher shows a small header with the profile name and a list under a heading about other profiles, and selecting an entry opens a separate window. The Google account switcher stays inside the page, lists email addresses, and reloads the current page in place. If the whole window did not change, the browser profile did not change.

The number in the URL is a position, not a name

Once two Google accounts are signed in to the same profile, Google addresses carry a number. Gmail becomes an address with a /u/0/ or /u/1/ segment, and Drive and Calendar do the same. That number is an index into the sign-in order for that storage area. It is not tied to an email address and it is not stable.

Sign out of one account and sign back in later, and the same number can point somewhere else. Anything that stored the old address keeps working and quietly opens the wrong identity: bookmarks, Dock shortcuts, saved links in a task manager, links pasted into documents months ago. The switch is fine. The address was pinned to a slot that has since been reassigned.

Two habits remove this class of problem. Stop bookmarking numbered addresses and enter Google services from their plain address, letting the in-page switcher pick the identity. Where a link has to be pinned, prefer the form that names the account rather than the slot: most Google services accept an authuser parameter carrying the email address, which survives a change in sign-in order.

Links arriving from outside the browser follow the default account

This is the version of the problem that survives every fix applied inside the browser. A link arrives in Slack, in a mail client, in a calendar invitation. It opens, and it opens under the wrong account no matter how carefully the switcher was set a minute earlier.

The decision is made before the page renders. When several accounts are signed in to one storage area, Google resolves the request against the default account, and the default is not something chosen in a settings screen. Google's account help states that in most cases the default account is the first one signed in.

That single sentence explains the asymmetry. Whichever identity happened to be signed in first that morning wins every ambiguous request afterwards. Changing it means signing out of every account in that storage area and signing back in with the intended one first, which ends every live session in that profile. It is a deliberate exercise, not something to attempt between meetings.

Signed in to Chrome and signed in to Google are not the same state

A second family of reports comes from a state mismatch. Chrome itself can be signed in to a Google account for the purpose of syncing bookmarks and passwords across machines. Separately, the websites open in that window have their own sign-in state. These two can drift apart.

The visible symptoms are familiar. Sync shows as paused while Gmail still works. A profile carries the name and photo of an account that the websites no longer treat as signed in. Selecting an account in the in-page switcher appears to succeed, then the page reloads under the previous identity because the underlying cookie was cleared and only the browser-level label survived.

The fix is to treat the two states separately. Sign out of the websites from a Google page, confirm the account list is actually empty, then sign back in. Repairing browser-level sync does not repair website sign-in state, and clearing all browsing data repairs website state at the cost of every other session in that profile.

When the account list is short, look outside the browser

Some readers never get as far as a failed switch, because the account that should be selectable is not offered at all. Three causes cover most cases.

A managed device is the first. On a Mac issued by a company or a school, an administrator can restrict which accounts may be added and which extensions may run. Google's own store documentation notes that an organization can block extensions on work and school computers, and the same class of policy governs account sign-in. No amount of local configuration changes it, so the fast path is to ask the administrator rather than to keep testing.

An extension is the second. Anything that blocks cookies, strips trackers or forces private-mode behaviour can interrupt the redirect chain that a sign-in depends on. The efficient test is to create an empty profile with no extensions installed and repeat the exact action. If it works there, the cause is local. If it fails there too, the cause is on the service side or on the network.

The third is that the account genuinely cannot be added, because the service does not allow two sessions at once. That is a property of the service, not of Chrome, and it is worth checking before spending an afternoon on browser settings.

Where the browser stops and the service takes over

Services differ in whether they can hold more than one identity in one storage area. Sorting the daily tools into that table costs a few minutes and saves a lot of guessing.

Service	Two identities in one profile	What breaks first
Google services	Supported through the in-page switcher	Links from outside follow the default account
Slack	Only for workspaces joined with the same email address	A different email address needs a separate storage area
Microsoft work and personal	Often unstable together	One session drops when the other refreshes
Most admin consoles	Not supported	The newer sign-in ends the older one

Sorting a tool into that table takes one look. Open the service, open its account menu, and check whether an option to add another account exists. If it does, the service can hold two identities in one storage area and the browser is rarely the obstacle. If it does not, the second identity needs somewhere else to live, and every hour spent on browser settings is spent on the wrong layer.

There is a second reason to do this early. Teams tend to standardise on one chat tool and one document tool, then accumulate consoles and dashboards that were never designed for shared use. Those late arrivals are usually the ones without a switcher, and they are usually the ones that end the session that mattered.

The pattern is easy to read. Where a service ships a switcher, the browser rarely needs changing and the real work is tidying up how links are stored. Where a service ships no switcher, no browser setting fills the gap and the only answer is a second storage area.

The cost of the workaround is the part rarely counted

Separate profiles do solve isolation, and the price is duplication. Extensions install per profile. Bookmarks grow separately. Settings drift. Passwords land in whichever profile happened to be open. At two profiles this is invisible. At four or five, keeping the environments consistent becomes a small recurring chore that nobody scheduled.

There is also a limit worth stating plainly. A profile is a separation, not a lock. Chrome's help notes that anyone using the device can switch to any of the profiles configured on it. Splitting client work into its own profile prevents mistakes. It does not restrict access, and it should not be treated as a security boundary.

Once several accounts and several services are in daily use, the question shifts. Instead of switching correctly, the better outcome is not having to switch at all: every account and every service holds a fixed place, and identity is implied by where something lives rather than confirmed before each action. That is the approach behind a browser that keeps each web app in its own window, described in Features, with the arrangement of several identities covered in Workspaces. Tools in the same category differ mainly in how far they carry the isolation and what they cost, which is the ground covered in Compared with Wavebox and Compared with Ferdium. Which services can be held this way is listed in Supported apps.

What to change first

Start with the addresses. Remove numbered Google URLs from bookmarks and shortcuts so that a change in sign-in order stops rerouting old links, and confirm whether the failing action is a browser profile switch or an in-page account switch before touching any setting. If the failure survives both, the cause is the default account or the service itself, and no browser configuration will reach it. When the daily routine involves more than two identities across more than a handful of services, giving each one a permanent place is a smaller ongoing cost than maintaining parallel profiles, and SpaceDeck is built for that arrangement.