Vivaldi workspaces: the setup order that holds up

Creating a workspace in Vivaldi takes about four clicks. The part that goes wrong happens later, usually in week two, when there are seven of them and no reliable answer to the question of which one a new tab belongs in. That failure is not caused by the feature. It is caused by building the workspaces before deciding what they divide.

This is the order that survives daily use: pick the unit, sort out profiles, build from tabs that are already open, assign one switching path, then automate where new tabs land. Each step depends on the one before it, and skipping the first two is what forces the rebuild.

Pick the unit before opening the workspaces menu

A workspace is a named, icon-tagged set of tabs that lives inside one browser window. That is the whole of it. Everything else in this setup is about deciding what those sets represent.

There are three units that people reach for, and mixing them is the single most common reason a setup collapses. By client, by role, by time of day. Each works. Any two of them together do not. A setup with a "Work" workspace, an "Acme" workspace, and a "Morning" workspace has no defined home for an Acme task done at 9am on a workday. Tabs without a defined home get opened wherever the cursor already is, and after a week the divisions exist only in the sidebar.

The test for a good unit is whether an arriving tab can be sorted without thinking. If a link from a client email has exactly one correct destination, the unit is right. If it plausibly belongs in two places, the unit is wrong and the setup will drift no matter how carefully the rest is configured.

Write the unit down before touching the browser. Then count something else: how many separate identities are in daily use. Work self, personal self, one per client. That number decides whether the next step is necessary or can be skipped entirely.

Profiles come first, workspaces come second

Workspaces do not separate logins. A Vivaldi user profile holds cookies, history, bookmarks, Speed Dials, and extensions, and can carry its own keyboard shortcuts and mouse gestures. Workspaces live inside a profile, which means every workspace under one profile shares one set of logins. Two workspaces with Gmail open are two views of the same Gmail account, and signing out in one signs out in both.

The practical consequence is about order, not preference. Building workspaces first and splitting profiles later means rebuilding every workspace inside the new profile, because nothing transfers across that boundary.

So the decision comes now. If the count from the previous step is one identity, skip profiles and move on. If it is two or more, and if being signed in to two accounts of the same service at the same time happens even once a week, add the profile now through the profile button and Manage People. On macOS, Vivaldi offers to create a desktop shortcut that opens straight into a given profile, which is worth accepting for any identity used every day.

The check that takes thirty seconds

Open the same service in two workspaces and compare the account shown in the corner. Matching accounts mean a shared profile and shared cookies. This check is worth running before building anything, because it settles the profile question with evidence instead of assumption.

Build the first set from tabs that are already open

With the unit chosen and profiles settled, creation is fast. Vivaldi offers two paths, and for the first pass the second one is faster.

The workspaces button sits at the left of the tab bar, or at the top of the list on a vertical tab bar. New Workspace asks whether to start empty or to move every tab from the current window into it, then asks for a name and an icon.

For a browser that already has dozens of tabs open, the better route is selective. Select the relevant tabs with Shift or Command, right click one of them, and choose to create a workspace from the selected tabs. Carving client by client out of an existing pile takes far fewer actions than creating empty workspaces and relocating tabs one at a time.

Name them specifically. A workspace called Work never expires, so it accumulates forever. A workspace named after a client or a project goes stale visibly when that project ends, which is what makes it possible to close it later without agonizing over the decision. The naming choice made here is what makes the final step of this process possible at all.

Assign one switching path and ignore the rest

Vivaldi offers at least six ways to move between workspaces: the workspaces menu, Quick Commands, keyboard shortcuts, scrolling the mouse wheel over the workspaces button, mouse gestures, and clicking a tab inside the Window Panel. Having six is not a problem. Trying to learn six is.

Choose one based on how many workspaces exist. Up to about five, the numbered shortcut is fastest: Ctrl+Shift or Command+Shift plus the position number, so the third workspace opens with Command+Shift+3. Past that point, remembering positions becomes the bottleneck, and typing the first few letters of a name into Quick Commands scales better. There are also actions for Next Workspace and Previous Workspace that can take shortcuts of their own, which suits a setup where the workspaces have a natural order.

Finish this step with the display settings, because they are quick and they stop being obvious later. With a distinct icon on each workspace, the names can be hidden to give tabs more room, through right clicking the workspaces button and turning off the name display. The whole menu can also be removed from the tab bar and placed elsewhere using the Toolbar Editor.

Decide where new tabs land before they arrive

Sorting tabs by hand is the part that eventually stops happening. Vivaldi has an answer for this in Settings, under Tabs and then Workspaces, where rules can move a tab automatically based on its URL. The example in the official documentation reads: if the URL contains bbc.com, open in News.

Rules pay off for destinations that never change. Client domains, internal tools, documentation sites, the ticketing system. They cost more than they save for anything whose correct destination depends on context, because an unexpected move is worse than no move at all. A tab that quietly relocated is a tab that has to be hunted for.

One related feature belongs in this step even though it solves a different problem. Right clicking a workspace offers to hibernate its tabs, which releases memory. It does not reduce the number of tabs and it does not stop notifications from those tabs. Vivaldi's own documentation is direct about the illusion involved, noting that dividing tabs into workspaces can make it feel like far fewer tabs are open than actually are.

Moving tabs after the fact

Rules handle new arrivals. Existing tabs that landed in the wrong place need one of two manual routes, and both are worth knowing before the first cleanup pass. The Window Panel lists every workspace as an expandable folder, so tabs can be dragged from one folder to another, with Shift or Command selecting several at once. The alternative is the tab bar context menu, where Move Tabs leads to a workspace submenu listing every destination by name.

For a cleanup of twenty or thirty stray tabs, the Window Panel is faster because both ends of the move are visible at the same time. For a single tab noticed mid task, the context menu takes fewer actions. Neither route closes anything, which makes both safe to use while working.

What this setup does not fix

After all five steps, three specific frictions remain. None of them are configuration mistakes. They follow from Vivaldi being one application on the desktop.

What happens	Why it happens	Whether setup helps
Notifications name the site, not the account	Site permissions are granted per profile and per site	No
Command+Tab arrives at the browser, not the workspace	macOS switches between applications	No
Window layout is lost on restart	Tabs are restored, window arrangement is not stored	No
The same workspace cannot fill two windows	A workspace opens in one window at a time	No, by design

That last row surprises people mid setup. Switching to a workspace already open in another window moves focus to that window instead of duplicating it. Anyone who wants a client chat on the left and client documents on the right has three options: tile tabs inside one window, split that client into two workspaces, or stop using workspaces for that particular pair and use two plain windows.

The first three rows are the ones worth measuring. Each costs a few seconds. The cost that matters is attention rather than time, and it scales with how many times a day the boundary gets crossed.

Two settings deserve a specific warning here, because they look like workspace settings and are not. Site notification permissions are stored per profile and per site, so a setup with three profiles means granting the same permission three separate times, and the resulting notification still arrives without an account name attached. Downloads also follow the profile, which means a file saved from a client workspace and a file saved from a personal workspace land in the same folder unless the profiles differ. Both are easy to miss during setup and both show up weeks later as a feeling that the separation is not holding.

Close a workspace without losing what was in it

The last step of the process is the one nobody plans for, which is why tabs get lost. Deleting a workspace closes every tab inside it. Anything worth keeping has to be moved to another workspace first. Tabs closed by accident can be recovered from the closed tabs list, but that is a rescue, not a plan.

There is a cleaner way to retire a workspace. Right click it and choose to copy all links, which produces a list of every URL open inside it. Pasted into a project handover note or an archive document, that list makes the workspace disposable without making it unrecoverable. The same action works on tab stacks and on any manual tab selection.

Set a rhythm for this. A monthly pass through the workspaces list, closing anything that has not been opened in that month, keeps the count near the number of identities actually in use. Specific names, chosen back in step three, are what make that monthly decision take seconds instead of minutes.

What to change first

Start with the unit, not the workspaces. Write down whether the division is by client, by role, or by time, and check that an arriving tab has exactly one home under that rule. Then count identities, and settle profiles before building anything, because that is the boundary that cannot be moved later.

If the count comes back at three or more identities, with the same service open under different accounts several times a day, the remaining friction is in the window layer rather than the tab layer, and the approach worth reading next is a browser that keeps each web app in its own window. The feature boundary is set out in Features, and the trade in price and scope against a subscription product is laid out in Compared with Wavebox. For a tab level problem, Vivaldi already has the answer and it costs nothing. For an identity level problem, the tool that fits is SpaceDeck.