Zen workspaces and containers are not the same thing

Zen ships with workspaces, and being built on Firefox it also inherits containers. Both are presented as ways to keep things apart, both live in the same sidebar, and both get recommended in the same breath whenever someone asks how to stop mixing work and personal browsing. They are not alternatives to each other. One reorganizes tabs on screen. The other changes which login a site sees. Setting up the wrong one produces a browser that looks tidy and still signs into the wrong account, or a browser that signs in correctly and is still impossible to navigate.

The distinction is worth getting right before any configuration happens, because the two features fail in completely different ways.

Workspaces sort tabs. Containers split identity

A workspace in Zen is a named set of tabs. Switching to another workspace swaps which tabs are visible in the sidebar and leaves the rest loaded but hidden. It is an organizational layer on top of one browsing session.

A container is a separate cookie jar. Firefox calls these contextual identities, and the Multi-Account Containers extension published by Mozilla is the interface most people use to manage them. A tab opened in the Work container carries a different set of cookies and site storage than a tab opened in the Personal container, which means the same site can be signed in as two different users at the same time.

Cookies downloaded by websites in one Container are not available to websites in other Containers. Source: support.mozilla.org

The test that separates them is simple: put the same site into two workspaces and it stays signed in as the same user, because a workspace never touched the cookie jar. Put the same site into two containers and it can be two users at once.

Everything else about the comparison follows from that one fact.

What a workspace changes

Workspaces are about attention, and they do that job well. A workspace holds its own set of tabs, its own pinned tabs, and in Zen its own visual theme, which makes the switch obvious rather than something to verify. Keyboard shortcuts move between them, and tabs can be dragged from one to another.

For a person running four projects, this removes the state that tab bars are bad at holding. Instead of forty tabs where six belong to today's task, there is a workspace with those six and three other workspaces waiting. Nothing is closed, so nothing has to be found again through history.

What a workspace does not do is change who the browser is. Every workspace shares one cookie jar, one history, one set of extensions, one download folder, and one set of saved passwords. Two workspaces both containing Gmail will both show the same inbox. That is not a bug in the feature. It is the boundary of what a tab grouping feature can be.

What a container changes

A container isolates cookies and site storage for the tabs assigned to it. Multi-Account Containers ships with four to start: Personal, Work, Banking, and Shopping. More can be created, renamed, and given a color, and the color appears as a line along the top of the tab so the current identity is visible without clicking anything.

The feature that makes containers practical for daily work is site assignment. A site can be set to always open in a particular container, so clicking a link to the company intranet lands in the Work container regardless of where the click came from. When a link arrives from outside the browser, Firefox opens it in the default context first and then offers to reopen it in the assigned container, which is a real step and not an instant redirect.

Containers stop at cookies and site storage. History is shared across all of them, so a work search still appears in personal autocomplete. Extensions run across every container. IP address and browser fingerprint are identical everywhere, which is why Mozilla positions containers as a tool for keeping accounts apart rather than as a privacy or anonymity tool.

Where they overlap in Zen

Zen closes part of the gap by letting a workspace carry a default container. When that is configured, new tabs opened inside the Client workspace start in the Client container, and the organizational layer and the identity layer stop drifting apart.

This is the setup most people are actually looking for when they compare the two features. The workspace answers where a tab lives. The container answers who the tab is. Binding them means one switch does both.

Two limits remain. First, existing tabs are not reassigned when the binding is set, so a workspace built before the container existed keeps its original tabs in the original context until they are reopened. Second, the binding governs new tabs opened inside the workspace, not links arriving from other applications, which still land in the default context and need the site assignment rule to be routed correctly.

An order of operations that avoids rework

Most of the frustration with this pair comes from configuring them in the wrong order and having to redo the work.

Start by listing the accounts rather than the projects. Two Google accounts, two Slack workspaces, a client Notion and a personal Notion. That list is the container list, and it should be short. Creating a container per project rather than per identity produces a set that grows without limit and stops meaning anything.

Next, assign the sites. Each container should own the domains that only ever belong to it. This is the step people skip, and skipping it is why links keep opening in the wrong context weeks later.

Then build workspaces around the work rather than around the accounts. A workspace is a task, a client, or a phase, and it can legitimately contain tabs from several containers, which is fine as long as the default is set correctly.

Finally, bind each workspace to the container it uses most. Open the tabs fresh inside the workspace after binding, since the binding does not retroactively move anything.

The order matters because containers are cheap to create and expensive to reorganize. Cookies do not migrate between containers, so every account moved to a different container means signing in again, re-approving two factor prompts, and losing whatever site preferences were stored locally.

Links from outside the browser are where this leaks

Both features assume the browsing session starts inside the browser. Real work does not. A link arrives in a mail client, a chat message, or a calendar entry, and the operating system hands it to the default browser with no information about which container or workspace it should belong to.

Firefox handles this with the site assignment rule, which catches the domain and offers to reopen the tab in the right container. That is a prompt, not a silent redirect, and the tab opens once in the default context before it moves. For sites where that first load matters, such as anything that records a session or logs an access, the behavior is worth knowing about.

Workspaces have a related quirk. A link opened from outside lands in whichever workspace is currently active, which may not be the one it belongs to. Moving it afterwards is a drag operation, and forgetting to do it is how a workspace slowly fills with tabs from three different projects.

Neither issue has a complete fix inside the browser. The closest thing to one is having fewer entry points, which is the reasoning behind giving each app a window that is always the same window.

What neither feature separates

Both features live inside one browser process and one application icon, and that shapes the rest of the day more than most comparison articles admit.

	Zen workspaces	Firefox containers	Browser profiles
Cookies and site storage	Shared	Separate per container	Separate per profile
Same site as two users at once	No	Yes	Yes, in separate windows
History and autocomplete	Shared	Shared	Separate
Extensions	Shared	Shared	Separate
Saved passwords	Shared	Shared	Separate
Separate window per boundary	No	No	Yes
Reached with Command Tab	No	No	No, all windows are one app

The last two rows are the ones that decide how a day feels. A workspace switch is a keyboard shortcut inside a window that is already focused. That is fast when the browser is already the active application and slow when it is not, because the operating system only knows about one browser. Any tool that keeps every boundary inside a single window inherits that ceiling, containers and workspaces included.

Profiles buy the extra separation at a cost. Extensions have to be installed twice, passwords live in two vaults, and switching still means finding the right window among windows that share one dock icon.

Choosing based on the failure that keeps happening

Rather than picking a feature and hoping it fits, name the failure first.

Signing in as the wrong account, or being logged out of one account by signing into another. This is a cookie problem. Containers fix it. Workspaces will not, no matter how carefully they are arranged.

Losing the tab, opening a duplicate, or reconstructing a set of tabs every morning. This is an organization problem. Workspaces fix it. Containers will not, and adding them makes the tab bar more colorful without making it smaller.

Both at once, which is the common case. Configure containers first, because the identity boundary is the one that produces wrong answers rather than slow ones. Then build workspaces around the projects, and bind each workspace to its container.

Switching is still slow after all of that. This is the failure that a browser setting cannot reach, because the constraint is one window and one application icon rather than anything about tabs. At this point the useful question is whether each app should have its own window rather than its own tab group.

Moving the boundary outside the browser

The alternative shape is a browser built so that each web app gets a persistent window and its own session, sometimes described as an app aggregation browser. Slack, Gmail, Notion, and a terminal sit in a fixed layout rather than in a tab strip, and a project is a set of those windows rather than a set of tabs. The Workspaces page covers how a set of apps is grouped and switched together, and the Features page describes which parts of a browser are kept and which are replaced. For a direct comparison against other tools in this category, the Rambox comparison sets out where the approaches differ on price, platform, and session handling.

This is not a strictly better answer. It costs money where Zen costs nothing, and it makes less sense for people who mostly browse rather than mostly work inside four or five services. The trade is a smaller surface for a faster switch.

What to change first

Set up containers for the accounts that have ever been signed into the wrong place, and add the site assignment rules for the two or three sites that matter most. Once the identity boundary is stable, build workspaces around projects and bind each one to its container. If switching still feels slow after that, the next thing to change is the window model rather than the browser settings, which is the question SpaceDeck is built around.