Firefox workspaces do not exist, so what do you use instead

Searching for firefox workspaces and then opening the Firefox settings is a short trip. There is no entry by that name. No panel, no sidebar switcher, no toggle buried under Appearance. The search still gets typed thousands of times a month, which means the thing being looked for is real even though the label is borrowed from somewhere else.

The useful move is not to hunt for a hidden setting. It is to work out which part of a workspace is actually needed, because Firefox splits that idea across three separate mechanisms that arrived at different times and solve different halves of the problem. Pick the wrong one and the setup falls apart in a week.

The word comes from other browsers, not from Firefox

Workspaces as a named browser feature belongs to Opera and to Vivaldi. Opera's feature page describes them as sets of tabs that live at the top of the sidebar, each with a chosen name and icon, switched with one click or a hotkey, and individually hideable. Vivaldi's page describes the same shape with one addition: selecting a workspace shows only that workspace's tabs in the window, and closing the browser saves them automatically.

Both descriptions share a defining property. A workspace in those browsers is a view filter over one set of tabs in one profile, not a separate identity. Switching workspaces changes what is visible. It does not change who is signed in. Anyone arriving at the Firefox search from an Opera or Vivaldi habit is usually looking for that: a named set of tabs, a one-click switch, and the confidence that the other set is still there.

Anyone arriving from Arc is often looking for something different and calling it the same word, because Arc's Spaces sit next to Arc's Profiles, and the two get conflated constantly in forum threads. That distinction is the whole decision here. A set of tabs is one problem. A set of signed-in accounts is another. Firefox has an answer to each, and they are not the same answer.

Tab groups: closest in feel, weakest at separation

Firefox tab groups are the direct match for the Opera and Vivaldi behaviour, and they are newer than most people expect. They began rolling out in Firefox 137, released on 1 April 2025.

Tab groups begin rolling out today! Stay productive and organized with less effort by grouping related tabs together. One simple way to create a group is to drag a tab onto another, pause until you see a highlight, then drop to create the group. Groups can be named, color-coded, and are always saved. You can close a group and reopen it later. Source: firefox.com

Three properties in that paragraph matter. Groups are named. Groups are color coded. Groups persist after being closed, which is the part that turns a group from a tidying gesture into something that survives a restart.

The gap is also visible in the same paragraph. A group is made by dragging one tab onto another, which means groups are built from tabs and stay tabs. They live on the same horizontal strip, in the same window, under the same login session. Twelve tabs in a group called Client A and twelve in a group called Client B are still twenty four tabs competing for the same strip of pixels, and both groups see the same cookies. Signing in to a second account of the same service inside a second group signs the first one out.

For someone whose problem is visual clutter, this is enough and nothing further needs installing. For someone whose problem is two Google accounts, it solves none of it.

Profiles: real separation, at the cost of a switch

Firefox's profile system is the mechanism that actually separates identities, and it was rebuilt into something usable one release after tab groups. Firefox 138, released on 29 April 2025, introduced profile management with names, avatars and colour themes, and described what it keeps apart: bookmarks, tabs and browsing history stay completely separate between profiles.

That is a much harder wall than a tab group. Two profiles can hold two Google accounts, two sets of extensions, two histories and two sets of saved logins, with no leakage in either direction. On macOS each running profile is its own window with its own entry in the app switcher, which also means each one can be assigned to a different desktop space if that is how the day is organised.

The cost is friction, and the friction is structural rather than cosmetic. Switching profiles means switching windows, and anything that needs to be visible in both places has to exist twice. A calendar that belongs to work and a calendar that belongs to a side project are two separate windows, and a link clicked in one profile opens in that profile, not in the one where the account for it lives. That last detail is the single most common reason people abandon a profile setup after a fortnight.

Profiles are the right answer when the boundary is permanent and rarely crossed. They are the wrong answer when the boundary gets crossed forty times a day.

Containers: many accounts inside one window

The third mechanism sits between the other two. Firefox Multi-Account Containers is an extension published by Firefox itself, currently listed on the add-ons site with 403,827 users and a 4.6 rating from 8,059 reviews. Its own description is precise about scope.

Under the hood, it separates website storage into tab-specific Containers. Cookies downloaded by one Container are not available to other Containers. Source: addons.mozilla.org

Containers are colour coded, renameable, and opened by long pressing the new tab button. A site can be assigned to always open in a given container, which is the setting that makes the whole thing practical: a work Gmail link always lands in the work container regardless of where it was clicked.

Two limits are worth knowing before committing. The separation described is website storage and cookies, not the browser as a whole, so bookmarks, saved passwords, extensions and history remain shared across containers. And containers are tabs, which means the clutter problem from the tab groups section comes straight back. Eight containers with three tabs each is still twenty four tabs.

Containers answer the account question with far less friction than profiles. They do not answer the window question at all.

Which mechanism matches which problem

Mechanism	Separates	Switching cost	Fails when
Firefox tab groups	Nothing. Groups tabs visually	One click, same window	A second account of the same service is needed
Firefox profiles	Cookies, history, bookmarks, extensions, passwords	A different window per profile	Both sides are needed at once, many times a day
Multi-Account Containers	Cookies and site storage only	One tab, same window	Tab count is already the problem
Opera or Vivaldi workspaces	Nothing. Filters which tabs are shown	One click or a hotkey	Accounts, not clutter, are the issue

Read down the failure column rather than the feature column. Every one of these mechanisms works exactly as described. The choice is made by naming which failure is tolerable, and that answer is personal rather than technical.

Stacking the three without building a maze

The three mechanisms are not exclusive, and the setups that survive longest usually use two of them with a rule about which does what. The rule matters more than the combination, because without one the same service ends up reachable from four places and no place is the obvious one.

A workable pattern starts at the identity layer and stops there until it is settled. One profile per identity set that has to stay signed in independently, with a hard cap of two or three, because every profile is a duplicated extension list, a duplicated password store and a separate window to raise. Anything below that line, meaning accounts that belong to the same working identity but need separate cookies, goes into containers inside a single profile. Anything below that line again, meaning pages that simply belong together, goes into tab groups.

The ordering matters because each layer constrains the one under it. Containers assigned to sites in one profile do not exist in another profile, so building containers before deciding the profile count means rebuilding them. Tab groups span containers inside a profile but never span profiles, so a group meant to hold a whole project falls apart the moment the project needs a second identity.

One detail catches people out regardless of the pattern chosen. The container extension is still an extension, which means it lives inside a profile and has to be installed and configured separately in each one. Two profiles running containers is two sets of site assignments to maintain, and an assignment changed in one does not appear in the other. Duplicated configuration is the real running cost of every layer added, and it is paid monthly rather than once.

What none of the three changes

Underneath all of this sits an assumption that no Firefox mechanism touches: that a web app is a tab. Gmail is a tab. Slack is a tab. Notion is a tab. Whatever is done with grouping, filtering or isolating, the daily tools remain items in a list that grows all day and is rebuilt every morning.

That assumption is what creates the specific failure everyone recognises. A tab has no fixed address. The Slack that was fourth from the left is now eleventh, so finding it means reading titles or scanning favicons rather than moving to a known position. Ten seconds of searching, forty times a day, is not a tidiness problem. It is roughly seven minutes of the working day spent locating things that were never lost.

A different category of tool starts from the opposite assumption: that each web app gets a permanent window of its own, with a fixed place to click, its own cookie container so a second account of the same service can stay signed in beside the first, and a named set of those windows that can be switched as a unit. That is the shape people are describing when they type the Firefox search, and it is why the search keeps happening despite the feature not existing. The idea of workspaces as separate signed-in spaces is a different design from grouping tabs, and comparisons such as how this approach differs from Wavebox are mostly arguments about where the boundary between apps should sit.

None of that makes Firefox the wrong browser. It makes the tab the wrong container for an app that is open every single day.

What to change first

Write down which of the three failures in the table is the one that actually costs time: a missing second account, a window switch, or a tab strip that cannot be read at a glance. If the answer is the first, install the containers extension today and assign five sites to containers, which takes about ten minutes. If the answer is the third, the fix is not inside a browser that treats apps as tabs, and a browser built around one window per app is the category to look at next, with terms and limits set out on the SpaceDeck pricing page.