Separating work and personal browsing: what it does and where it breaks down

Two browsers sit in the Dock. One carries the work Google account, the team chat, and the client consoles. The other carries personal mail, banking, and everything that should never surface during a screen share. The arrangement holds for a week, then something crosses. A link from a work message opens under the personal identity. A notification fires and nothing on screen says which side it came from. The useful question at that point is not how to repair the split but what the split was ever able to control, because several of the common complaints describe things it was never holding in the first place.

One phrase covers five different setups

People describing the same practice are often running different machinery. The table below sets out what each arrangement actually keeps apart on a Mac.

Setup	Kept apart	Still shared
Two browser applications	Cookies, extensions, history, saved passwords, site permissions	Downloads folder, the default browser role, Dock and app switcher behaviour
Profiles inside one browser	Bookmarks, history, passwords, cookies, extensions per profile	The application itself, one Dock icon, link routing, the process family
Firefox Multi-Account Containers	The cookie jar assigned to a tab	History, extensions, the window, bookmarks
A second macOS user account	Everything the operating system tracks, files included	Nothing, at the cost of not having both sides open in one session
A dedicated multi-account browser	A session per app window, so two accounts of one service coexist	Depends on the product, and the free tiers differ

The rows are ordered by how much they hold and how much they cost in daily friction. The second macOS user account is the strictest boundary available short of a second machine, and almost nobody keeps it, because crossing means logging out. Most people end up somewhere in rows one to three and then discover that those rows do not hold everything they assumed.

Knowing which row applies matters because the failures are row specific. A container cannot be given its own set of extensions. A second browser application cannot receive links based on where the link came from. Asking a row to do something outside its design produces an unfixable bug report.

What the boundary genuinely holds

Within a single profile or browser application, four things are genuinely kept apart, and these are the reasons the practice is worth the trouble at all.

Sessions. Each profile holds its own cookie store, so a login on one side is invisible to the other. This is the load bearing part. It is also the part that produces the most confusion, because one cookie store holds one session per site. Two accounts on the same service inside one profile evict each other by design, not by fault.

Extensions and their permissions. An extension installed on one side is absent on the other, and so is the access it was granted. A personal shopping extension does not get to read a client console. A corporate security extension does not get to read personal banking.

History and autofill. What gets typed into an address bar on one side does not suggest itself on the other. This matters more than it sounds during a screen share, when the address bar is the most exposed surface on the machine.

Site permissions. Camera, microphone, location, and web notification grants are stored per profile. A site allowed to send notifications to the work side is not allowed on the personal side unless granted again.

Google's own description of the profile feature stays within these bounds and does not claim more:

With profiles, you can keep all your Chrome info separate, like bookmarks, history, passwords, and other settings. Source: support.google.com

Info separate is an accurate and modest claim. Everything listed there lives inside the browser. Nothing outside it is covered.

Four things stay shared whatever the setup

The complaints that never get resolved are usually about things sitting outside the browser, where no profile setting reaches.

The Downloads folder. A file saved from the work side and a file saved from the personal side land in the same place with the same naming rules. An invoice, a contract draft, and a holiday photo end up adjacent. Browsers allow a different download location to be set per profile, which helps, but it is a manual setting on each side rather than something the split does automatically, and files dragged out of a chat client bypass it entirely.

The clipboard. Copying a client credential on one side and pasting into a personal document on the other works exactly as it always does. macOS keeps one clipboard per login session, and Universal Clipboard extends it to other Apple devices signed into the same iCloud account. Nothing about a browser split narrows it.

The network path. A VPN, a proxy, a DNS filter, or a corporate network profile applies to the whole machine. Personal browsing on a Mac connected to a work VPN traverses the work network regardless of which browser window it came from. Anyone who split browsers specifically so that personal traffic would take a different route has not achieved it at this layer.

The screen. Screen sharing during a call captures a display or an application window, not a profile. A notification banner from the personal side lands on a shared screen exactly as any other banner does. The only controls that help here are the operating system notification settings and a deliberate choice about which application is running during a call.

None of these are faults. They are simply outside the scope the split was ever able to cover, and recognising that early saves a great deal of unproductive configuration.

The boundary has no authority over incoming links

This is the first place the model breaks, and it accounts for most of the crossings people report.

macOS holds exactly one default web browser setting, found under System Settings in Desktop and Dock. A link clicked in Mail, in a chat client, in a calendar invitation, or in a PDF goes to that one application. Nothing in the click carries an instruction about which identity should receive it. Once the link reaches the browser, the browser hands it to whichever window was most recently in front.

The consequence is that the identity receiving a work link is decided by focus history rather than by the origin of the link. Reading a personal message at lunch, then clicking a link in a work calendar invitation an hour later, is enough to open a client console under the wrong account. No setting inside the browser changes this, because the decision was made before the browser was involved.

Three responses exist and each has a cost. Bringing the intended window forward before clicking works and depends entirely on memory. A third party link routing utility can inspect the URL and dispatch to a chosen application or profile, which adds a component to maintain. Arranging matters so each service occupies a fixed window removes the routing question rather than answering it, because there is only ever one place a given service can appear. Which response fits depends on how often the crossing actually happens, which is worth counting for a day before deciding.

Notifications arrive without the side attached

The second break is notifications, and it is structural rather than accidental.

A web push notification carries the site and the message. It does not carry the profile. Two arrivals from the same service, one work and one personal, produce two visually identical banners. Clicking one usually opens the profile that registered it, so the routing is normally correct, but the read is ambiguous at the moment it matters, which is while attention is on something else.

Focus modes make this sharper. macOS filters notifications by application. A Focus that silences a personal browser works cleanly when the personal side is a separate application. It cannot work at all when the personal side is a profile inside the same application as the work side, because the operating system sees one application and has no visibility into profiles. Anyone who split by profile and then tried to build a working evening Focus has met this limit.

The workable arrangements are narrow. Keep the personal side in a different application so Focus has something to target. Or turn off web push for the services that generate the noise and check them deliberately. Or use a tool where each service is its own window and notification settings are set per window. The one arrangement that does not work is expecting profile level filtering from an operating system that does not model profiles.

Separation is not protection

The third break is a misreading rather than a defect. A split is an organising tool and not an access control, and the documentation is explicit about the difference:

Only share your device with people you trust. If someone has your device, they can switch to any other Chrome profile on it. If they open your Chrome profile, they can see info like what websites you visited. Source: support.google.com

Anyone at the keyboard can switch sides. There is no password between profiles and no lock on a browser window. The same holds for two separate browser applications, which are simply two icons an unattended person can click.

This matters for two decisions. If the goal is keeping a client's data away from a household member who uses the same Mac, the layer that does that is a macOS user account with its own login, not a browser profile. If the goal is keeping work identity out of personal browsing and keeping the screen presentable during calls, a browser level split is exactly the right size of tool.

Treating a browser split as a security boundary tends to produce elaborate arrangements that solve nothing. Treating it as a filing system, and then handling access control at the operating system layer where it belongs, produces a simpler setup on both counts.

Signs the arrangement has stopped fitting

Three patterns indicate that no further tuning will help and the layout itself is the problem.

The first is crossing frequency. A split costs nothing when the two sides are visited in blocks, morning on one and afternoon on the other. It becomes a task of its own when contexts alternate several times an hour, because every alternation is a window hunt with a chance of landing wrong.

The second is the same service on both sides. One mail provider, one chat tool, or one cloud suite used with two accounts is the case that generates repeated sign in prompts inside a single profile and forces a full application switch across two applications. It is also the case that dedicated multi-account tools were built for, and the point where their free tiers start to differ from each other.

The third is dependence on memory. When correct behaviour requires remembering which window is in front before every click, mistakes are a matter of probability rather than carelessness. Arrangements that put each service in a fixed place remove the recall step instead of asking for more discipline. The window model behind that approach is described on Workspaces, and what gets held separately per app is listed on Features. Whether the specific services in use are covered can be checked on Supported apps.

What to change first

Identify which of the five setups is actually running, then check whether the complaint is inside the browser or outside it. Link routing, notification identity, and access control all sit outside, and no amount of profile tuning will move them. If the count of daily crossings is high and the same service appears on both sides, the next thing to evaluate is a fixed place per service, which is the model described on SpaceDeck.