Arc workspaces, and where they leave you now

Anyone who has built out Arc with a Space for work, a Space for a side project, and a Space for everything personal has already solved a real problem. Tabs stopped being one undifferentiated pile. The sidebar remembers what belongs together. The question that shows up a few months later is different: whether that arrangement is actually separating accounts, and whether it is worth rebuilding somewhere else now that Arc has stopped receiving new features. Both questions have clear answers, and they are not the same answer.

The short version is that Arc has two mechanisms that both get called workspaces in casual conversation, they draw boundaries in different places, and only one of them touches logins.

Spaces and profiles are not the same boundary

A Space in Arc is a named set of tabs with a pinned section, a color, and its own slot in the sidebar. Switching between Spaces is a swipe or a keyboard shortcut, and it is fast. What a Space does not do on its own is give those tabs a separate cookie jar. Two Spaces in the same profile share one login state, which means the same Gmail account is signed in to both, and signing out of one signs out of the other.

A profile in Arc is the thing that holds cookies, site storage, history, and extensions. It is the same concept Chrome uses, because Arc is built on Chromium. A Space can be assigned to a profile, and that assignment is what makes two Spaces genuinely different identities rather than two views of the same identity.

The practical rule is that Spaces organize attention, and profiles organize accounts. Most frustration with Arc traces back to expecting one of these to do the other one's job. Someone who builds five Spaces inside a single profile has a beautiful sidebar and exactly one set of logins. Someone who builds five profiles but never assigns them has isolation that never comes into play.

How to tell which one is in effect

Open the same service in two Spaces and check whether the account indicator matches. If it does, the Spaces are sharing a profile. Arc shows the profile assigned to a Space in the Space settings, and changing it after the fact does not migrate any tabs or sessions. The tabs stay where they are and the logins change underneath them, which is why the switch feels like everything broke.

Where a Space stops being a boundary

Even a correctly assigned Space runs into three limits, and none of them are bugs. They come from Arc being one application.

Notifications arrive with a site name and no identity. A message badge says Slack, not which Slack. That single missing detail is enough to force a switch just to find out whether the notification was worth reading.

Command Tab lands on Arc. macOS treats the whole browser as one target, so the fast application switcher takes the reader to the browser rather than to the account. From there, the sidebar has to be read, the Space has to be picked, and the tab has to be found. Three steps replaced one.

A crash or a restart brings back the tabs but not the arrangement of windows. Arc restores Spaces reliably. What it does not restore is a two window layout with the work Space on the left and reference material on the right, because that layout was never stored anywhere.

None of this makes Spaces a bad mechanism. It makes them a mechanism for organizing tabs inside one window, which is what they were built to be. The reader who feels friction here is usually asking the sidebar to solve a window management problem.

The settings that follow the profile, not the Space

Three settings surprise people because they sit at the profile level even though the mental model puts them at the Space level. Site notification permissions are granted per profile and per site, so three profiles means granting the same permission three times, and the granted notification still arrives without an account name attached. Extensions are installed per profile, which means a password manager unlocked for a personal vault is live on every Space assigned to that profile. Download location is also a profile setting, so files from a client Space and files from a personal Space land in the same folder unless the profiles differ.

None of these is severe on its own. Together they explain why a setup that looks separated on the sidebar still feels mixed in daily use.

What Spaces got right, and what to carry forward

It is worth naming the parts that work, because a migration that drops them is a downgrade even if the new tool is better on paper.

Spaces made the current context visible at a glance. The color and the name in the sidebar answer the question of where the reader is without any action. Any replacement needs an equivalent, whether that is a distinct window position, a distinct icon, or a distinct color.

Spaces also made the pinned set meaningful. A pinned tab in Arc is a permanent slot rather than a tab that happens to be first, and that distinction between permanent tools and temporary reading is the single most useful idea in the whole model. It transfers to any browser and to any tool: decide which services get a permanent home and which get closed at the end of the day.

The third thing worth carrying forward is the habit of naming. A Space named after a client is a commitment, and it makes the end of an engagement visible. Setups that use generic names like Work and Other decay faster, because nothing in them ever expires.

The status of Arc, stated plainly

In 2025 The Browser Company said publicly that Arc would no longer receive new features, and that development effort had moved to a different browser aimed at a different idea. The company was later acquired by Atlassian. Arc continued to be distributed and to receive security updates, and Chromium based browsers inherit engine level security fixes from upstream, so the near term risk is not that the browser stops opening.

The medium term question is different. A browser in maintenance means the sidebar, the Spaces model, and the profile assignment behavior will keep working the way they work now, and will not grow. For a reader whose setup already fits, that is close to a feature: nothing will move. For a reader who is waiting on a missing capability, the wait is over and the answer is no.

That distinction is worth being honest about before rebuilding anything. Migration has a cost, and the cost is not worth paying to escape a browser that currently does the job.

What the alternatives actually separate

The word workspace means something different in each product, which is the main reason comparisons go wrong. This table uses the reader's question rather than the vendor's vocabulary.

Approach	Separate logins	Separate window per context	Layout survives restart	Switching target
Arc Spaces, one profile	No	No	Tabs yes, layout no	Sidebar
Arc Spaces, profile per Space	Yes	No	Tabs yes, layout no	Sidebar
Chrome profiles	Yes	Yes	Windows yes, arrangement no	Dock or avatar menu
Safari profiles	Yes	Yes	Windows yes, arrangement no	Menu
Edge Workspaces	No	No	Tab set yes	Menu
Firefox Multi-Account Containers	Yes, per container tab	No	Tabs yes	Tab bar
A browser that keeps each web app in its own window	Yes, per app	Yes	Yes	Application switcher

Two rows deserve a note. Edge Workspaces is a shared and synced set of tabs, built for collaboration rather than isolation, so it sits in the same column as Arc Spaces on the login question. Firefox containers are the most granular option available for free and the only one that puts two accounts of the same service in one window without a second profile, at the cost of leaving everything in that one window.

The last row is a different category rather than a better browser. Treating each web service as an application, with its own window and its own dock presence, moves the switching target from a sidebar to the macOS application switcher. The Workspaces page describes how that grouping is arranged by project rather than by service, and the Features page covers which browser behaviors are kept and which are deliberately left out.

Rebuilding a Spaces setup somewhere else

Anyone moving off Arc tends to try to recreate the sidebar first. That is the wrong starting point, because the sidebar is the part that is easiest to reproduce and the least valuable.

Start by writing down the identities, not the services. Company self, personal self, one entry per client. This list is usually shorter than the list of Spaces, because Spaces tend to accumulate around projects that ended. Every service belonging to an identity goes in the same container, whatever the container turns out to be.

Then decide which services are genuinely visited every day. A service opened twice a month does not need a permanent home. It needs a bookmark. Setups get heavy because monthly tools were given the same status as hourly ones.

Only then pick the mechanism. If the identities are few and the switching is rare, Chrome or Safari profiles cover it at no cost. If the same service has two accounts that need to be visible at the same time, containers do it in one window. If the identity count is small but the service count is high and the switching happens dozens of times a day, the constraint is window management rather than cookies, and the answer lies in giving each app its own window. Comparisons against the closest tools in that category are on the Compared with Wavebox and Compared with Sidekick pages, which is the fastest way to see whether the model fits before installing anything.

Export before anything else

Whatever the destination, bookmarks and passwords should be exported first, while the current browser is still installed and working. Chromium based browsers export bookmarks to an HTML file and passwords to a CSV file from their own settings, and both formats import cleanly into any other Chromium based browser. Doing this at the start rather than at the end removes the pressure to finish a migration in one sitting, because the old setup can stay in place as a reference for a week without blocking anything.

Do not migrate the tab pile

The temptation during a migration is to move all of it. Open Spaces, count the tabs, and move the ones that are real. Most Arc setups carry a long tail of pinned tabs that were pinned once and never opened again. A migration is the cheapest moment in the year to drop them, and the only moment when doing so feels like progress rather than loss.

What to change first

Check whether the Spaces in use are assigned to different profiles, because that single setting decides whether anything is actually separated. If they are, and switching still costs attention, the remaining problem is window management rather than session isolation, and it is worth reading how SpaceDeck draws that boundary at the application level instead of inside a sidebar.