A Biscuit browser review and what replaced it on Mac

Most searches for the Biscuit browser come from one of two places. Either a Mac is running twenty open tabs of Gmail, Slack, Notion and a couple of client dashboards, and something lighter looks appealing. Or Biscuit was already installed months ago, a laptop got replaced, and half the setup did not come back. Those are different problems, and only one of them is solved by installing Biscuit. What follows is what the app actually does today, taken from the product's own documentation, and what has to be true of anything that takes its place.

What Biscuit is, on its own description

Biscuit is a desktop browser built around web apps rather than pages. The sidebar holds groups and apps, the tab bar shows tabs belonging to the current app, and links opened inside an app stay attached to that app. The product's own help page states the intent plainly: keep app-like services in Biscuit and leave general browsing to the default browser.

The distribution terms are unusually simple for this category. The site offers builds for macOS on Intel, macOS on Apple silicon, Windows and Linux, and describes the product as free, with no tracking and no account required. There is no plan table, no trial countdown and no seat count. The site carries a 2026 copyright line for the Biscuit Project and runs in English, Japanese and German.

For anyone whose only requirement is grouping a handful of daily services without paying for anything, this is a short evaluation. Download it, add the apps, done. The evaluation gets longer the moment multiple accounts, multiple machines or client separation enter the picture, because those are the areas where the differences between products in this category actually live.

Two structural points are worth fixing in mind before comparing anything. First, the unit of organisation is the app, not the tab. Second, there is no server-side account holding the setup together, which is a privacy advantage and a portability cost at the same time.

The session model is the part that matters

Signing into three accounts of the same service is the single most common reason people leave a normal browser, and Biscuit's answer is specific. By default, apps do not share sign-in state with each other. Each app keeps its own session, so signing into one does not sign in another. The marketing page gives the practical version of this: multiple accounts of the same service can stay open side by side.

There is an opt-out. Enabling Shared Session for a group makes the apps inside that group behave like one shared browser profile. The help page attaches a warning to it, and the warning is the useful detail: turning Shared Session on asks for a fresh sign-in to the apps affected, because the session model genuinely changes underneath them.

That leads to a practical ordering. Decide the session layout before adding fifteen apps, not after. A group per client with isolation left on is the layout that survives growth. A group with Shared Session enabled suits tightly connected tools that expect to share a login, such as several properties of one vendor behind a single identity provider.

The other half of this is where the credentials live. Biscuit can offer to save a username and password after a sign-in form is submitted, with saved entries reviewable in its Password Manager. The documentation is explicit that saved passwords, cookies and sign-in state stay local to the device. Nothing about that is unusual for the category, but it sets up the next section, which is where most of the disappointment in this product comes from.

Cloud sync carries structure, not sign-in state

This is the point that turns a good review into a bad week, so it is worth quoting the shape of it exactly. Biscuit's cloud sync is described as intentionally limited. It carries top-level workspace structure, notification settings, shortcut settings and other device-independent settings. It excludes credentials, cookies, saved passwords, sign-in state and URLs in local child tabs.

What sync includes: Top-level tab structure, notification settings, shortcut settings, and other device-independent workspace settings. Source: eatbiscuit.com

Read that against the laptop replacement scenario from the opening. The shape of the setup comes back. The logins do not. For someone running two personal accounts, that is twenty minutes of annoyance. For a contractor holding twelve client accounts across four services, each with its own two-factor method, it is most of a working day, repeated every time hardware changes.

Biscuit does offer two adjacent mechanisms. It keeps backups and can restore from a backup list, and it supports export and import of app and tab settings for moving structure to another machine. Both move structure. Neither moves the thing that actually takes time to rebuild.

There is also a conflict rule worth knowing before two Macs are in play. If another device syncs first, Biscuit can restore the latest synced workspace and asks for a review before overwriting it again. That is a reasonable design, but it means the answer to which machine holds the authoritative layout is decided by sync order rather than by a setting.

Notifications and keyboard movement

The day-to-day quality of any product in this category comes down to two things: whether interruptions can be shaped, and whether switching costs a mouse trip.

On interruptions, Biscuit controls notifications at the level of the individual app and at the level of the whole application. An app's notifications can be turned on or off from its right-click menu, a global button mutes everything for focus time, and the unread badge can be switched between a dot and a number in Settings. The help page notes that some services expose custom unread logic, so counts can feel more app-aware than a plain browser tab. That is the real argument for this category over tab groups, and it is a stronger one than the tidiness argument that usually gets made.

On movement, the shortcut set is short enough to memorise. The app switcher opens on Cmd + O, Ctrl + Tab and Ctrl + Shift + Tab step through it, Cmd + B toggles the sidebar, Cmd + L focuses the address bar, and Cmd + / opens the shortcut help dialog. Number shortcuts can target either apps or tabs depending on a setting, which explains the most common complaint about them behaving unexpectedly.

Anyone evaluating this category should test exactly one thing on day one: how many keystrokes it takes to get from the busiest app to the second busiest. Feature lists do not capture that, and it is the cost paid several hundred times a week.

Why people look for a replacement

The searches that pair this product with the word alternative cluster around four things, and none of them is the price.

The first is sync, covered above. A setup that cannot carry sign-in state is a setup that has to be rebuilt by hand on every new machine.

The second is the boundary between apps and general browsing. The product's own guidance is to leave ordinary browsing to the default browser. That is honest, and it means a second browser stays in the dock. Some people want that separation. Others find that the research tab, the documentation tab and the pull request all end up in the wrong window.

The third is extensions. An ad blocker, a password manager and a clipping tool are load-bearing for many people, and the Chrome Web Store is the assumed source. Where a product in this category does not support them, the workflows built on them have to move somewhere else.

The fourth is support and continuity. A free product with no account and no subscription has no support contract either. For a hobby setup that is fine. For a setup that holds client work, some people prefer a paid product specifically because a paid product owes something in return.

What a replacement has to match

Comparisons in this category usually list features. A more useful frame is what each product gives away for free, since that is where the real constraint sits. The figures below come from each vendor's published pricing, checked on 18 September 2026.

Product	Free tier as published	Paid
Biscuit	Free, no account required, no plan tiers listed	None listed
Wavebox	2 groups, 2 apps in each, 1 extension, 1 dashboard	$8.33 per month, paid annually; Teams $12.50 per user per month
Rambox	Unlimited apps, up to 2 instances per app, no workspaces or multi-login	$7.00 per month or $70.00 per year; Teams $14 per user per month, from 5 users
Ferdium	Open source, community built, no published plan limits	None

Three things follow from that table. Free is not rare in this category, so free on its own is not a reason to choose anything. The limits that bite first are usually counted in accounts and workspaces rather than in apps. And the products that charge tend to charge for exactly the two things the free tiers withhold, which are multi-account isolation and sync across machines.

That gives a concrete shopping list. Isolation per app, confirmed by signing into the same service twice. Sync that states in writing what it carries and what it drops. Notification control at the app level. A switcher reachable without the mouse. How different products in this category answer the first two is set out side by side in Compared with Wavebox and Compared with Ferdium, and the way per-app containers are built is described in Workspaces.

Moving a setup across without losing a day

Whether the destination is a different product or a second Mac, the migration work is the same, and it is almost entirely about credentials rather than about layout.

Start by writing the setup down before touching anything. Every app, which account it holds, which group it sits in, and whether that group shares a session. Biscuit's export of app and tab settings produces a file that captures structure, and it is worth keeping as a record even when the destination cannot read it. A plain list in a note does the same job and can be read by anything.

Next, deal with two-factor recovery before the old machine is wiped. Authenticator codes tied to a device are the single most common reason a two hour move becomes a two day one. Confirm that every account in the list can be recovered from something other than the machine being replaced.

Then rebuild in the order that reflects actual use. The two or three apps that carry the working day go in first and get tested properly, including notifications and the unread badge. The long tail of services checked once a week can wait, and some of them will turn out not to be worth re-adding at all, which is a quiet benefit of any migration.

A setup rebuilt in priority order is usable after an hour even when it is only a third complete. A setup rebuilt alphabetically is unusable until the last item lands. The same rule applies whichever product ends up holding the apps, and the list of services that can be added at all is worth checking first in Supported apps.

What to change first

Before installing anything, write down how many accounts of the same service need to be signed in at once, and whether the setup has to survive a new Mac. Those two answers eliminate most of the category in about five minutes. When both answers are more than trivial, look at how a tool keeps containers separate and what its sync actually carries, which is where SpaceDeck sits in this comparison.