Opera workspaces are tab groups with a new name

Most people arrive at Opera workspaces from the same place. The tab strip has stopped being readable, every favicon looks like every other favicon, and somewhere in that row is the Slack tab that has been loaded since Monday. Opera's answer is a set of icons down the side of the window, each one holding its own tab strip. It is a real improvement over one long row. It is also a smaller change than the marketing around it suggests, and knowing exactly where the line falls saves a week of rearranging things that were never the problem.

This covers what a workspace is at the mechanical level, what the five slot limit does to how people use it, how it lines up against Chrome tab groups, and the one category of problem that no tab layer solves.

What a workspace is, mechanically

Opera's own help page is unusually plain about the concept, which is helpful, because the word "workspace" has been used to mean six different things across six different products.

Think of workspaces as pockets for tabs, you can keep them empty, or you can fill them. Source: help.opera.com

A pocket is the right image. A workspace holds tabs and nothing else. It does not hold a session, a set of cookies, an extension configuration, or a login. Switching workspaces swaps the contents of the tab strip and leaves everything underneath it exactly where it was.

The controls sit in two places. The workspace icons live at the top of the sidebar, and clicking one jumps to it. Everything else happens in the sidebar setup panel, reached through the three dot menu at the bottom of the sidebar. From there workspaces can be turned on or off entirely, added, renamed, given a different icon, removed, or hidden from the icon strip while staying alive in the background.

Moving tabs between pockets works the way it should. Right-clicking a tab offers Move tab to workspace, and shift-clicking several tabs first moves the whole selection. Links can be sent directly to a destination: right-click the link, hover Open link in workspace, pick the target. That last one is the detail that changes daily behaviour most, because it means a link found while researching does not have to land in the workspace where it was found.

The scoping of ordinary tab commands is the part worth reading twice. Reload all tabs only reloads the tabs in the current workspace. Cycling tabs with Control and Tab only cycles the current workspace. In other words, the pocket is not just a visual filter. Commands respect the boundary, which is what makes a workspace feel like a separate place rather than a saved filter over one large pile.

The five slot limit

Opera's help page states the cap directly: workspaces can be added up to 5 currently. People discover this at the point where they have made one for work, one for a side project, one for reading, one for shopping, and then want a sixth for the thing they are actually doing this week.

The limit reads as an arbitrary restriction. In practice it functions as a design constraint that pushes toward the layout that works anyway. Switching is done by clicking an icon in a vertical strip, and a vertical strip of icons is only fast while every icon is distinguishable at a glance. At five, the hand learns positions. At twelve, choosing an icon becomes the same search problem that the tab strip had, moved sideways by a hundred pixels.

The cap does force a decision about what deserves a slot. Two rules make that decision easier.

The first is to give slots to things that start and stop, not to things that always run. A client project, a quarter's planning, a trip being booked: these have a beginning and an end, and a pocket that can be emptied suits them. Email and chat do not end, which is the case for pinning them in whatever workspace is used most rather than isolating them where notifications go unseen.

The second is to name slots after the work rather than the category. "Reading" collects things forever and is never opened deliberately. "Q4 budget" is opened on purpose, and it is obvious when it can be emptied.

Hiding is the pressure valve people miss. A hidden workspace still exists and still holds its tabs; it just stops occupying a position in the icon strip. Work that comes back every few weeks can live hidden between appearances, which keeps the visible set down to the three or four that are genuinely live.

Workspaces next to Chrome tab groups

The closest comparison is Chrome's tab groups, and the two solve the same problem from opposite directions. Chrome keeps one tab strip and lets sections of it collapse. Opera keeps several tab strips and swaps which one is showing.

	Opera workspaces	Chrome tab groups
Where it lives	Icons in the sidebar	Coloured sections in the tab strip
How many	Up to 5	No stated limit
Switching	Click a sidebar icon, strip swaps	Collapse one section, expand another
Survives closing	Yes, stays in the sidebar	Yes, saved to the bookmarks bar or menu
Syncs across machines	Tied to Opera's sync	Synced when browsing history and tabs are synced with a Google Account
Deleting	Removes that workspace locally	Removes the group on that device and other devices on the same account
Separates logins	No	No

Two lines in that table matter more than the rest.

The first is what happens on delete. Chrome's help is explicit that deleting a tab group removes it on that device and on other devices using the same Google Account, and that ungrouping does the same to the group even though the tabs stay open locally. Tidying up on a laptop at the end of the day can therefore dismantle a saved arrangement on the desktop machine. Anyone running two machines should know that before a cleanup session, not after.

The second is switching cost. Collapsing and expanding a group keeps every group visible in one strip, which is good for comparing across groups and bad once there are more than a handful. Swapping a whole strip hides everything except the current context, which is good for focus and worse when the answer needed is in the pocket that is not showing. Neither is better in the abstract. The load that distinguishes them is how often the switch happens: a handful of times a day favours a swapped strip, and constant back and forth favours everything staying visible.

A layout that survives past the first week

Most workspace setups collapse for the same reason most folder systems collapse. The arrangement is built during an hour of enthusiasm, when every distinction feels meaningful, and then it is used during ordinary days, when nobody wants to decide where a link belongs. The layouts that last are the ones that need no decision at the moment a tab is opened.

Three habits carry most of that weight.

Default everything into one pocket. Pick the workspace where most of the day happens and let new tabs land there without thought. Sorting happens later, in one pass, not tab by tab. A pocket that requires a filing decision every time a link is clicked stops being used within days, and the tabs pile up in whichever workspace was open at the time anyway.

Move by selection, not one at a time. After a research session, shift-click the run of tabs that belong together and use Move tab to workspace once. The feature exists for exactly this, and it turns cleanup into a ten second action rather than a chore that gets postponed.

Empty a pocket when the work ends. A workspace attached to a finished project should be emptied, not renamed into something vaguer. Renaming is how a slot becomes a permanent drawer of things nobody will open, and with only five slots available, a drawer is expensive. Anything worth keeping goes to bookmarks; the rest closes.

One more habit helps on machines with several accounts in play. Before a cleanup session on a second machine, check what is synced. Chrome's behaviour on deletion reaches other devices on the same account, and an evening spent tidying a laptop can quietly rearrange a desktop setup that was working fine.

What no tab layer separates

Both approaches share one boundary, and it is the boundary that sends people looking for a new browser every few months.

A workspace does not separate identity. Two tabs of the same service in two different workspaces still draw on one cookie jar. Logging into a second Google account in one pocket changes which account is active in the other pocket, because the pockets hold tabs and the profile holds the session. Anyone splitting work and personal, or running several client accounts on the same platform, hits this in the first hour and concludes the feature is broken. It is not broken. It is operating exactly one layer above the layer where the problem lives.

The layers, from the outside in, are: tabs, then tab organisers like groups and workspaces, then browser profiles, then separate browsers or containers. Sessions are decided at the profile layer. That is why the common workaround is running two browsers all day, with the second one open for nothing but a single login.

Notifications sit near the same boundary. A chat app in a workspace that is not currently shown is still loaded and can still fire notifications, but the application is not designed around staying dormant for hours in a hidden strip. The usual compromise is a pinned tab that lives in whichever workspace is used most, which quietly reintroduces the mixing that the workspaces were supposed to end.

Deciding which layer the problem is on

The useful measurement is not how many tabs are open. It is how many times a day the same five or six destinations get switched between.

If most of the tabs are research, reference, and things opened once and closed, the problem is genuinely at the organiser layer. Workspaces, or tab groups, will fix it, and nothing further is needed. Sorting the current pile into four pockets and naming each after a piece of work usually restores a readable window in one sitting.

If the same handful of destinations are visited dozens of times a day, and especially if two of them need two different logins, the problem is one layer down. No amount of pocket arrangement changes a session boundary. The tools that do operate at that layer give each service its own persistent window with its own session, which is the model behind workspaces in browsers built around app aggregation rather than page browsing. Whether that is worth switching for depends mostly on whether the daily tools are supported, and the supported apps list answers that faster than a trial does. Products in this category differ more than their descriptions suggest, so a direct comparison such as compared with Sidekick is the quickest way to see where the real differences sit.

What to change first

Turn on workspaces, make three, and name them after work that ends rather than categories that do not. Give it a week and count the switches. If the count is high and two of the destinations need separate logins, the next move is the profile layer rather than another arrangement of pockets, and SpaceDeck is one of the tools built for that layer.