Wavebox: what it does and where it breaks down

Wavebox turns up in two very different conversations: people drowning in tabs, and people trying to stay signed in to four Gmail accounts at once. The descriptions that come back are equally split. Some call it a mail client, some call it a browser, some call it a workspace. All three are partly right, which is exactly why the picture stays fuzzy. The accurate description is narrower: it is a Chromium desktop browser where the primary unit of navigation is an app rather than a tab, and where login state is stored in a container you control. Knowing that changes which questions are worth asking about it.

It started as a mail client, and that still shows

The published timeline explains more about the product than the feature list does. It launched in 2016 as WMail, an Electron application for handling several mail accounts. In 2019 the foundation moved from Electron to Chromium. In 2020 a language model was wired into the browser itself. A team product was rebuilt in 2023, and the interface and spaces were relaunched in 2024.

That origin matters because it sets the order in which problems were solved. The first problem was staying signed in to several accounts of the same service at once. Everything else, including tab organisation, was built outward from that. A product that starts as a tab manager and later adds account separation ends up with a different shape, because account separation has to be retrofitted into a model that assumes one identity per window.

The foundation being Chromium has practical consequences worth stating plainly. Rendering and security updates follow Chromium. Extensions from the Chrome Web Store install and run. Anything Chromium cannot do, this cannot do either. The company behind it is based in the UK and states publicly that it operates without venture funding, and that it is being monitored and audited for SOC 2 and ISO 27001 compliance. None of that tells you whether the tool fits your day, but it does tell you what kind of organisation is maintaining it.

Four layers, and only one of them holds your logins

The vocabulary is where most people stall. Four terms appear in the interface and they sound interchangeable. They are not.

Layer	What it is	What it separates
Profile	A fully separate environment	Settings, extensions, passwords, everything
Space	A cookie container	Sign-in state only
Group	A cluster of apps in the sidebar	Visual arrangement, colour, unread badge
App or tab	The page itself	Nothing. It belongs to a space

The space is the load-bearing concept. The knowledge base is explicit about what it used to be called:

Spaces (previously known as cookie containers or cookie profiles) allow you to stay signed-in to multiple app/website accounts and use them side-by-side without conflicts. Source: hub.wavebox.io

Because a space is a cookie container, the count of spaces sets the ceiling on how many accounts of the same service can stay signed in at once. Three Gmail accounts require three spaces. This is the difference from a Chrome profile: a Chrome profile owns a window, while several spaces coexist inside a single window.

Groups are the rounded squares in the vertical sidebar. Each carries its own colour, icon and unread badge, and each holds a horizontal strip of apps and tabs. A group has a space attached to it, so anything opened while working inside that group lands in that space automatically. That is a default rather than a rule, and a single group can hold apps from more than one space. Profiles sit outside all of it. Nothing crosses between them in either direction, and switching happens from an icon in the top right corner.

What it adds on top of a stock Chromium browser

The feature list is long, but it divides cleanly into two kinds of things: mechanisms for gathering accounts, and mechanisms for moving quickly once they are gathered.

On the gathering side: spaces holding separate sign-ins, apps that stay authenticated rather than being reloaded from a bookmark, and published support for more than 2,500 services with per-service handling of icons, unread counts and sleep behaviour. Chrome Web Store extensions install normally, and more than 20 extensions ship built in.

On the movement side, four things do most of the work. A global search bound to a keyboard shortcut covers apps, tabs, widgets and notes in one query. A cycle shortcut moves through the five most recent apps. Split screen puts two pages side by side, including two accounts of the same service, so two calendars from different Google accounts can sit next to each other. A link engine decides which app a clicked link opens in, so a link pasted into a chat opens in the destination app rather than in a new anonymous tab.

That last one is worth singling out. Once several accounts are signed in simultaneously, every link becomes an ambiguous instruction: open this, but as whom. Handling that automatically is the difference between a browser that stores several identities and one that can actually be used with several identities. Any tool in this category should be evaluated on how it answers that question, not on how many services appear on its compatibility page.

Where the model breaks down

Four things reliably cause trouble, and none of them are missing features.

The profile and space distinction is not intuitive. The vendor maintains a separate article explaining which to choose, which is a fair signal that people get it wrong. Deciding after the fact is expensive: converting a space into a profile means re-authenticating everything inside it.

The second is the free ceiling. The free tier allows two spaces, two groups with two apps in each, one extension and one dashboard. That accommodates a work account and a personal account. It does not accommodate a third client, and it does not accommodate running an ad blocker and a password manager at the same time. Anyone planning to stay on the free tier permanently should check the count before investing setup time, and the Pricing page for tools in this category is the fastest way to see where each one draws that line.

The third is platform scope. macOS 12 Monterey or later is required, on both Apple Silicon and Intel machines, with Windows and Linux builds also available. Older hardware still running an earlier macOS is excluded before any of the feature comparison matters.

The fourth is structural rather than technical. Consolidating everything into one window concentrates the failure. A stock browser with a dead tab costs you a tab. A single window holding twelve signed-in accounts, when it slows down, slows down all twelve at once. Chromium memory usage scales with what is loaded, so the number of always-on apps needs a limit that you set deliberately. Related to this: only web applications participate. Native Mac applications installed from the App Store stay outside the arrangement entirely, so the more of your day happens in native software, the less of it this consolidates.

What the free tier covers, and what passing it costs

The published pricing has three tiers, and the free one is defined by counts rather than by disabled features.

Tier	Price	What changes
Basic	Free	Two spaces, two groups of two apps, one extension, one dashboard
Pro	99 USD per year	Unlimited spaces, groups, apps and profiles, any extension, profile sync
Teams	150 USD per seat per year	Adds shared dashboards, central admin, consolidated billing

Every account begins with a seven day trial of the paid tier, with no card required, and a 30 day refund window is published. A 70 percent discount exists for education and non-profit use, applied by starting a trial from a .edu or .org address and then contacting support rather than automatically.

The number to watch is not the monthly figure. It is the per account figure. Two accounts fit inside the free tier, so nobody with two accounts should be paying anything. Ten accounts spread across clients bring the annual price under ten dollars per account, which is a different comparison entirely. Decide which of those two situations describes you before comparing prices at all.

Compared with running several Chrome profiles

Most people arriving at this category are already solving the problem some other way, and usually that way is Chrome profiles. Understanding the difference in mechanism is more useful than any feature table, because the two approaches fail differently.

A Chrome profile owns a window. Switching identity means switching windows, and a window carries exactly one identity at a time. That is a clean model and it works, right up to the point where a task requires two identities simultaneously. Reading one client's calendar while entering something into your own is the standard example. With profiles, that means two windows, arranged manually, with no shared search across them and no combined view of what is unread.

Spaces invert that. Several containers live inside one window, so two identities can be visible at once, search covers all of them in a single query, and unread counts from every container aggregate into one place. What you give up is the hard wall. A Chrome profile is genuinely isolated: separate extensions, separate settings, separate everything. A space isolates cookies and sign-in state and nothing more. The equivalent hard wall exists here as a profile, one layer up, and it comes with the same costs isolation always brings.

The practical translation is a question about your work rather than about software. Does the day require looking at two accounts at the same moment, or merely being able to reach both of them? If both accounts only ever need to be reachable, profiles in a stock browser already solve it and switching tools buys little. If two accounts routinely need to be on screen together, no amount of profile switching produces that, and the container model is the thing that does.

There is a third case worth naming: needing both, with a hard boundary around one part. That is what the two layer arrangement exists for, and it is why the space and profile distinction is worth getting right before building anything.

Moving in costs time in re-authentication, not in setup

Installation takes minutes. Bookmarks and passwords import from Chrome or Edge, and the documentation states that passwords do not leave the machine during the copy.

The cost sits after that. Separating accounts into spaces means signing into each account again, inside its own container. Every service with two factor authentication extends that process. Estimating migration time by counting services understates it; count the authentication steps instead.

The workable approach is to refuse to migrate everything at once. Fill one space with the handful of things opened every day, run on that for a week, and only then decide whether the model earns the rest. Tools in this category diverge mainly on how they handle notifications, how many accounts they permit, and what they charge, which is what Compared with Rambox and Compared with Sidekick set out side by side.

What to change first

Spend a few days noticing which problem actually costs you time: accounts of the same service bleeding into each other, or rebuilding your screen every time you switch between projects. The first points toward container based separation, the second toward keeping each task on its own surface, which is the arrangement described under Workspaces and detailed on Features. SpaceDeck lists what that approach costs, and deciding which of the two problems you have is the only step that has to happen before anything else.