Microsoft Edge workspaces and the account problem they leave open

Anyone reading about Microsoft Edge workspaces today is reading two different products at once. Articles written a couple of years ago describe a collaboration feature with shared tabs, live cursors and colleagues joining a link. The version shipping now does none of that. The name stayed and the product underneath it was replaced, which is why forum threads about workspaces disappearing and workspaces changing keep appearing.

Sorting out which version is being described takes a few minutes and saves building a workflow on a feature that no longer works the way an article promised. The more useful question sits one level down: what an Edge workspace separates, and what it leaves untouched.

What the current version requires and does

Microsoft's own getting started page sets the boundaries plainly. The requirements are a desktop running Windows 10, Windows 11 or Mac OS, desktop only, with Microsoft Edge version 144 or later, and being signed into Edge with a Microsoft (MSA) account or an Azure Active Directory (AAD) account.

Two details in that list are worth pausing on. The first is that mobile is absent. There is no Edge workspace on iOS or Android, so a workspace is a desktop arrangement rather than something that follows a person to a phone. The second is that the account requirement is a sign-in requirement, not a licensing one. The current version does not require Microsoft OneDrive storage, which the earlier version did.

Creating one is a short flow. A name and a theme are chosen, Done is selected, and the workspace opens in a new browser window. At the point of creation there is a choice between carrying the tabs that are already open into the new workspace or starting with a blank one.

What it produces is a window holding a named, coloured set of tabs, synced to the signed-in account so the same set can be opened on another machine. The unit of organisation is the tab, and the boundary is a window, not an identity.

The collaboration version is gone, which changes what old advice is worth

The clearest statement about the current scope is a single line on Microsoft's support page.

Sharing, collaboration, and joining workspaces are not supported. Source: support.microsoft.com

The same page states that others cannot be invited to join an Edge workspace. Earlier versions were built around exactly that: a shared set of tabs that two people could sit in at the same time, with the workspace data living in OneDrive or SharePoint. A team that adopted workspaces for handovers or for shared research was using a feature that has since been narrowed to a personal one.

This matters practically rather than historically. Anyone evaluating Edge workspaces from a blog post, a video or a recommendation from a colleague should check the date of the advice before acting on it. A comparison written against the collaborative version will credit the feature with capabilities it no longer has, and a workflow designed around shared workspaces has no current equivalent inside Edge.

The narrowing also explains why the feature is easier to reason about now. Without sharing, a workspace is simply a named window of synced tabs. That is a smaller claim, and a smaller claim is easier to check against what is actually needed.

What a workspace does not separate

The question that sends most people looking at workspaces in the first place is about accounts. Two Microsoft accounts, a work Google account and a personal one, two Slack sign-ins, a client's tenant and an internal one. Keeping those live at the same time is the friction that makes a day feel slow.

A workspace does not address that. Tabs inside a workspace live in the signed-in Edge profile, and cookies belong to the profile rather than to the workspace. Two workspaces created inside one profile will both open the same signed-in mailbox. Naming one of them for a client does not give it a separate cookie jar.

Edge does have a mechanism for the account layer, and it is the profile, which is the same answer Chrome gives. Chrome's help page describes the scope of a profile in one sentence.

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

Sign-in state travels with that same boundary in both browsers. The practical consequence is that workspaces and profiles are not alternatives to each other. A profile decides who is signed in. A workspace decides which tabs are in front of that identity. Using the second where the first is needed is the most common reason a workspace setup stops feeling useful after a few weeks.

Edge's other organising features, and where each one sits

Edge ships more than one way to arrange things, and they are easy to confuse because the interface presents them near each other.

Tab groups collect tabs under a label inside a window, in the same way Chrome's do. They sit in the same place as workspaces conceptually, one level down: a group is inside a window, a workspace is the window.

Split screen is a different idea again. Microsoft's policy documentation describes it as a feature that lets a user open two web pages in one tab, supported on Windows and Mac from version 117. That is a viewing arrangement for comparing two pages, not an organising structure, and it shares the cookies of the tab it lives in.

Vertical tabs change where the tab strip is drawn. On a wide screen this makes long tab titles readable, which raises the practical ceiling on how many tabs can be scanned. It does not change what a tab is.

Stacking these is where setups go wrong. Each one is cheap to turn on, so it is tempting to run all of them and hope the combination adds up to separation. It does not, because four of the five sit on the context or view layer and only the profile sits on the account layer. A person running workspaces, tab groups, split screen and vertical tabs at once has four ways to arrange the same session and still one identity underneath. The symptom is a setup that looks organised in a screenshot and still requires signing out to reach the other account.

Feature	Layer it works on	What it separates	What it cannot do
Profiles	Account	Cookies, sign-ins, passwords, extensions, history	Fix where a window sits on screen
Workspaces	Context	A named window of tabs, synced to the account	Separate sign-in state
Tab groups	Context	A labelled set of tabs inside a window	Separate sign-in state
Split screen	View	Two pages visible in one tab	Anything about identity or storage
Vertical tabs	View	Nothing. Changes where tabs are drawn	Anything about identity or storage

Reading the last column first is faster than reading the feature names. All five work as described. The choice is about which unsolved problem is the expensive one.

Three layers, and the one no browser staffs

Stepping back from feature names, every setup for keeping work contexts apart is operating on one of three layers.

The account layer decides whether two identities can be signed in at once. Profiles handle this in Edge, Chrome and Firefox alike, and Firefox added a rebuilt profile manager in version 138, released on 29 April 2025, which keeps bookmarks, tabs and history separate between profiles.

The context layer decides which pages sit together. Workspaces, tab groups and Firefox's own tab groups, which arrived in version 137 on 1 April 2025, all live here.

The window layer decides where a service physically sits on screen and how many actions it takes to reach it. No mainstream browser staffs this layer, because every one of them treats a web app as a tab.

That third layer is where the residual friction usually lives for someone who has already set up profiles correctly and already uses workspaces. The mailbox that was fourth from the left in the morning is eleventh by the afternoon. Reaching it means reading titles or scanning favicons instead of moving to a known position. Ten seconds of searching, repeated forty times, is roughly seven minutes of a working day spent locating things that were never lost, and the cost that matters is the broken context rather than the minutes.

Finding out which layer is actually short

Guessing at this produces expensive rebuilds. Counting produces an answer in a day.

For one working day, mark every switch between services and note which of three things happened next to the mark: a sign-in was needed or an account had to be changed, a page had to be hunted for, or a window had to be found and raised.

A high first column means the account layer is unmanaged, and the fix is profiles. The number of profiles equals the number of identity sets that must stay signed in at once, and keeping that number at two or three matters because every profile is a duplicated extension list and a duplicated password store.

A high second column means the context layer is unmanaged. Workspaces and tab groups are the tools, applied inside one profile at a time.

A high third column means the window layer is unmanaged, and no Edge feature addresses it. This is the case where more organising produces less and less return, because the structure is already correct and the problem is that everything still lives in a list that is rebuilt every morning.

A different starting assumption for the window layer

One category of tool starts from the opposite premise: that a frequently used web app should have a permanent window of its own rather than a position in a list. Each service keeps a fixed place to click, its own storage so a second account of the same service can stay signed in beside the first, and a named set of those windows that switches as a unit.

That combination covers the account layer and the window layer at the same time, which is why it reads as familiar to anyone who has tried to make workspaces do the job of profiles. The mechanics of one service per window, and what switching between sets actually looks like, 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 differ mainly in how the storage boundary is drawn and where the free tier stops, which is usually a limit on windows or accounts rather than on core functionality. A direct comparison against the best known product in the category sits on Compared with Wavebox, and the shape of the charge is on Pricing.

What to change first

Settle the account layer before touching anything else, because profile boundaries determine what sync reaches and what a workspace can span. Then use workspaces and tab groups inside each profile for the context layer, which is the job they actually do. Only when both are in place is the remaining friction clear enough to judge whether the window layer needs a dedicated tool such as SpaceDeck, and by then one counted day says how much that would be worth.