What a Chrome workspace can and cannot keep separate

Searching for a workspace in Chrome returns settings pages, extension listings and forum threads that all answer slightly different questions. That is because Chrome ships no feature under that name. What exists are two separate mechanisms, profiles and tab groups, and each one separates a different thing. Most of the frustration behind the search comes from expecting one of them to do the other one's job.

Sorting this out takes about ten minutes and it saves rebuilding a setup twice. The useful question is not which feature is the workspace. It is which of three layers is currently unmanaged.

The three layers, named

Every setup that keeps work contexts apart is working on one of three layers.

The account layer. Cookies, sessions, saved passwords, extensions. This is what decides whether two Google accounts can stay signed in at the same time, or whether one signs the other out.

The context layer. Which pages are grouped together, and whether that grouping survives closing the window. This is about finding things, not about identity.

The window layer. Where a service physically lives on screen, and how many actions it takes to reach it. A service that is always in the same window at the same size is reached in one step. A service that lives in a tab somewhere is reached by hunting.

Chrome staffs the first two layers and leaves the third one empty. That gap is where the search for a Chrome workspace usually starts, even when the person searching would not describe it that way.

What a Chrome profile separates

Chrome's own help page states the scope plainly.

With profiles, you can keep all your Chrome info separate, like bookmarks, history, passwords, and other settings. Source: support.google.com

Cookies and sign-in state travel with that same boundary, which is the part that matters most in practice. Two profiles can hold two Google accounts signed in simultaneously, two Slack workspaces, a client's Notion and an internal one. Nothing crosses. For anyone whose daily friction is being signed out of one account by signing into another, the profile is the correct tool and no amount of tab organisation substitutes for it.

Two constraints come with it. The first is that deletion is destructive: removing a profile erases that profile's bookmarks, history, passwords and settings from the computer. Creating is cheap, merging later is not, so the number of profiles is worth deciding deliberately rather than growing by accident.

The second is that switching is a menu action. With two profiles this is invisible. With five, the act of choosing becomes part of every context change, and the setup starts to feel like overhead rather than structure. Profiles scale well in separation and badly in switching frequency.

What tab groups separate

Tab groups sit on the context layer. They collect open tabs under a label, they can be collapsed, and closing one does not throw it away. Chrome's help describes the persistence and the sync behaviour directly: a closed group is saved to the bookmarks bar or the menu and can be reopened, and when browsing history and tabs are synced with a Google Account, changes to tab groups are saved and synced across devices on that account. Deleting a group removes it on the other devices too.

What tab groups do not touch is identity. Two groups inside one profile share every cookie in that profile. A group named for one client and a group named for another will both open the same signed-in Notion, the same signed-in Gmail. Grouping is a filing system laid over a single identity.

This is the single most common mismatch behind the search. Someone needs client accounts kept apart, builds tab groups because they are easier to set up, and concludes weeks later that the approach failed. It did not fail. It was applied to the wrong layer.

Layer	Handled by	What it separates	What it cannot touch
Account	Chrome profiles	Cookies, sessions, passwords, extensions, bookmarks	Window position, notification routing
Context	Tab groups	Which pages sit together, saved and synced	Sign-in state, identity
Window	Nothing built in	Where a service lives on screen	Everything above

Extensions and sync follow the profile boundary, not the group boundary

One consequence of the layer split gets overlooked until it causes a problem. Extensions are installed per profile. A password manager, an ad blocker, a screen recorder, a client's required security extension: each is present in the profile it was installed into and absent everywhere else. Someone who splits work across four profiles is maintaining four extension sets, and an extension updated or reconfigured in one does not change in the others.

That cuts both ways. A client that mandates a monitoring extension can have it confined to the profile used for that client's systems, rather than running across personal browsing. A rarely used extension with broad permissions can be quarantined the same way. The cost is upkeep, and the benefit is a real boundary, so the number of profiles is also a decision about how much duplicated configuration is acceptable.

Sync follows the same line. Tab group changes propagate to other machines signed in to the same Google Account, which is convenient when a laptop and a desktop should show the same structure, and disruptive when a tidy-up on one machine rearranges a session in progress on another. Because the sync identity is attached to the profile, choosing profile boundaries is also choosing how far that propagation reaches. A separate profile for a second machine's workflow stops the spillover without turning sync off.

Downloads, site permissions and notification allowances are also per profile. The notification list is worth opening once per profile and pruning, because permissions accumulate quietly and a profile built for focused work often carries a dozen sites permitted to interrupt it.

Edge uses the word, for something narrower than it sounds

Microsoft does ship a feature called Workspaces, which is why the term circulates. Reading its current requirements is worth doing before assuming it is the missing piece, because the feature changed substantially.

Microsoft's support documentation lists the requirements as a desktop running Windows 10, Windows 11 or Mac OS, Microsoft Edge version 144 or later, and being signed in with a Microsoft account or a Microsoft Entra account. The current version also states that sharing, collaboration and joining workspaces are not supported, and that it no longer requires OneDrive storage. Earlier versions of Edge Workspaces were built around real-time shared tabs between colleagues, so older articles describe a different product than the one shipping now.

Stripped to what it does today, an Edge workspace groups related tabs into one window and syncs that grouping. That places it on the context layer, next to Chrome's tab groups, rather than on the account layer. Even within a shared workspace, Microsoft's enterprise documentation notes that logins, passwords, extensions and cookies are not shared between participants. The word workspace does not imply a separate cookie jar in either browser.

Telling which layer is actually missing

Counting beats guessing here, and one working day is enough data.

Keep a tally of every switch between services. Next to each mark, note which of three things happened: a sign-in was required or an account had to be changed, a page had to be searched for, or a window had to be found and raised. The distribution points at the answer.

A high count in the first column means the account layer is unmanaged. The fix is profiles, and the number of profiles equals the number of identity sets that need to stay signed in at once.

A high count in the second means the context layer is unmanaged. The fix is tab groups, applied within one profile at a time.

A high count in the third means the window layer is unmanaged, and neither Chrome feature addresses it. This is the case that generates the search in the first place. Someone has already set up profiles correctly, already uses tab groups, and still spends the day hunting for the window that has Slack in it.

A three-day sequence that produces evidence

Doing this in order matters, because each step changes what the next one is measuring.

Day one is the tally described above, with the setup left exactly as it is. The output is three numbers, not an impression.

Day two addresses whichever layer scored highest. If it was the account layer, write down the sets of identities that must stay signed in at once, create exactly that many profiles, and move nothing else. If it was the context layer, build tab groups inside a single profile first rather than across all of them at once.

Day three repeats the tally. A change that solved the right problem shows up as a visible drop in one column and roughly flat numbers in the others. A change that solved nothing shows all three columns unchanged, which is information: the layer being addressed was not the one causing the friction.

The reason to keep this mechanical is that browser setups are easy to rebuild on enthusiasm and hard to evaluate afterwards. Two counted days cost almost nothing and prevent the far more expensive outcome, which is migrating an entire working setup into a different tool and discovering that the original problem is still there.

What sits in the window layer

Two approaches exist for the third layer. One is at the operating system level: macOS Spaces and window management tools fix where windows sit, without touching cookies at all. A window can be pinned to a desktop, but two Google accounts still cannot be signed in simultaneously inside it.

The other is a browser built so that each service gets its own persistent window with its own storage, which covers the account layer and the window layer at the same time. Tools in this category differ mainly in what they fix in place and how the storage boundary is drawn, which is worth reading about specifically rather than from a feature list. The mechanics of one service per window, and how switching between them works, are set out on Workspaces. What else moves into the window once a service lives there permanently, including notification handling and restoring state at launch, is covered under Features.

Products in this category price differently, and the boundary between free and paid usually falls on the number of windows or accounts rather than on core functionality. Comparing the shape of the charge, not only the monthly number, is the useful exercise: the details for one such tool are on Pricing, and a direct feature comparison against the best-known product in the category is on Compared with Wavebox.

Change one layer at a time, starting at the bottom

Fix the account layer first, since profile boundaries determine what sync can reach and what tab groups can span. Then build tab groups inside each profile. Only after both are in place does the residual friction show clearly enough to judge whether the window layer needs a dedicated tool such as SpaceDeck, and by then the tally from that one counted day says exactly how much it would be worth.