Multiple login accounts on one PC: pick the right layer

One machine, two working lives. A work identity and a personal one, or two clients, or a company account and a side project. The advice that turns up is a pile of unrelated procedures: add a user in System Settings, create a browser profile, add a second account inside Gmail. All three are real answers. They answer different questions, and none of the articles tends to say which one.

The useful way in is not to compare the methods. It is to name the mix-up that is actually happening, because the layer that fixes a wrong document folder is not the layer that fixes a message sent from the wrong address.

Start from the mix-up, not from the method

There are three boundaries available on a Mac, nested inside each other. The operating system user account is the outermost. Inside a single user account, a browser can hold several profiles. Inside a single profile, a service such as Google or Slack can hold several signed in accounts of its own.

Each boundary is stronger and more expensive than the one inside it. Choosing well means matching the boundary to the specific thing that keeps going wrong.

• Files, downloads, and app settings land in the wrong place. That is an operating system problem, and only the outermost layer moves it.
• The wrong tab is signed in, saved passwords bleed across contexts, extensions meant for work are running on personal sites. That is a browser storage problem, and the profile layer handles it.
• Only the destination of a click is wrong, and everything else is fine. That is a service level problem, and the innermost layer is enough.

The reason this matters is that the layers are not interchangeable. A reader who separates macOS users because a Gmail address keeps getting picked wrongly has spent an afternoon building a wall in the wrong place and will still pick the wrong address, because the browser inside the new user account will develop the same habit within a week.

The outermost boundary and what it costs

A separate macOS user account splits everything the operating system knows about: the home folder, the desktop, per user app preferences, the keychain, and every browser profile inside it. If a machine is shared with another person, this is the correct layer and nothing weaker will do.

Apple documents the switching mechanism plainly.

If your Mac has multiple users, an administrator can turn on fast user switching, which allows you to quickly switch between accounts when more than one user is logged in at the same time. Source: support.apple.com

Being logged in at the same time is the convenience and the bill. Every session that stays logged in keeps its apps and background processes resident. Two browsers logged in at once means two full sets of browser processes, whether or not either window is visible. On a machine that was already running warm, the second session is felt immediately.

The second cost is friction. Switching swaps the entire screen. Notifications for the other identity arrive where nobody is looking. The clipboard does not travel. For someone who crosses between work and personal a dozen times an hour, the strength of this boundary converts directly into lost time. For someone who crosses it twice a week, the strength is free.

The rough rule is frequency. Several crossings a day makes this layer too heavy. Weekly or less makes it the cleanest option available.

Browser profiles separate storage, not access

For one person splitting contexts on a machine nobody else touches, the profile layer is usually the right size. Chrome profiles hold separate history, cookies, saved passwords, extensions, and bookmarks, and two profiles can be signed into the same service at the same time in two windows.

What separates is storage. What does not separate is access, and Google states this directly.

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

So the profile layer is the right tool for stopping personal mistakes and the wrong tool for stopping other people. Anyone whose actual requirement is privacy from a housemate or a colleague needs the outer layer, and the distinction is worth settling before building anything.

One more property catches people out. Profiles belong to a single browser. A link opened from a PDF, a chat client, or a mail app goes to the system default browser and lands in whichever profile that browser opened last. The separation holds inside the browser and evaporates at the edge of it.

In-app switching is fast and narrow

The innermost layer is the account switcher inside the service itself. Add a second Google account and move between them from the avatar menu. Add a second Slack workspace and it appears in the sidebar. Nothing outside the service changes, which is why this is where most people start.

It works well for reading. Checking whether something landed in the other inbox, opening a file that was shared with the other identity, glancing at a calendar: short round trips with no writing involved.

Three things it does not do. It rarely shows two accounts of the same service side by side, because most services hold one active session per window. It does not control where an incoming link lands, so a shared URL opens under whichever account was last used and produces a permission screen and a manual retry. And it leaves extensions and notifications shared, so a tool installed for work runs everywhere and a personal alert arrives in the middle of a work call.

The honest boundary for this layer is writing. If both identities are only being read, it holds. If both are being written in every day, the friction accumulates faster than the setup cost of moving up a layer.

What each boundary actually separates

What gets separated	macOS user	Browser profile	In-app switching
Documents and desktop	Yes	No	No
Cookies and session state	Yes	Yes	Yes
Saved passwords	Yes	Yes	No
Extensions	Yes	Yes	No
Download location	Yes	Configurable	No
Where notifications come from	Yes	No	No
Two accounts visible at once	No	Yes	Rarely
Cost per switch	High	Medium	Low

Two rows deserve attention. Notifications do not separate at the profile layer, because every profile is still one application talking to the notification system, so an alert gives no clue about which identity it belongs to until it is opened. And the row for showing two accounts at once is the only row where the middle layer is clearly ahead, which settles the choice for anyone whose work involves comparing two accounts rather than alternating between them.

Deciding without rebuilding twice

Three questions settle the layer in about five minutes, and answering them in this order avoids the common outcome of building a boundary, living with it for two weeks, and tearing it down.

The first question is whether anyone else physically uses the machine. If the answer is yes, the decision is already made and the outermost layer is required, because nothing below it restricts access. If the answer is no, that layer can be set aside entirely, along with most of the search results about adding users.

The second question is whether the two identities are ever needed on screen at the same moment. Comparing two calendars, copying a value from one account's dashboard into the other, watching two inboxes during a handover: any of these rules out the innermost layer, because a single window holds a single session. Alternating with a gap of minutes between visits does not rule it out.

The third question is how many crossings happen in a normal working day. Under about five, almost any arrangement holds. Between five and thirty, the profile layer is usually the balance point, since it separates storage without swapping the whole screen. Above thirty, the layer stops being the interesting variable, because the switching itself has become the cost.

Answering in that order matters because the questions get progressively softer. Shared access is a hard constraint. Simultaneous visibility is a task requirement. Crossing frequency is a preference that changes with the job. Building on the hard constraint first means the setup survives when the softer answers move, which they do whenever a project ends or a client is added.

Why one side keeps getting signed out

A common follow up complaint, a week after the boundary is built, is that one context needs a fresh login every morning. Three causes account for most of it, and none of them is a flaw in the layer that was chosen.

The first is a setting or an extension that clears browsing data on exit. Privacy tools frequently remove the storage that keeps a session alive along with everything else. If it happens in one profile only, disabling that profile's extensions one at a time finds it quickly.

The second is a limit on the service side. Services cap how many accounts can hold a live session at once, and adding more evicts the oldest. Reducing the number of accounts added to the switcher stops it.

The third is private browsing used as a separation method. Sessions there are discarded by design when the window closes, so logging in every time is correct behavior and no amount of settings review will change it.

Two problems no boundary solves

Whichever layer gets chosen, two things survive.

The first is that nothing on screen says which identity is active. Two profile windows look nearly identical, and the only signal is a small avatar. Mistakes here are not carelessness, they are a display problem, and the discovery usually happens after the send button. Theme colors and fixed window positions help, and they are still a system that depends on somebody looking.

The second is the number of crossings. Choosing a layer decides where the wall stands. It does not reduce how often the wall is crossed, and every crossing carries a small reload of context. Someone crossing thirty times a day crosses thirty times a day regardless of which layer holds the wall.

Both of these come from the same root. As long as several identities take turns inside one window, separated by time rather than by place, the same symptoms appear at every layer.

What to change first

Count the crossings for one week before changing anything, and note which of the three mix-ups is actually happening. If the count is low, the layer already in use is fine. If the count is high and every crossing still involves a switcher menu, the fix is not a stronger boundary but a fixed place for each identity, which is what SpaceDeck is built to provide. The Features page covers how far the separation goes, and the Supported apps list shows which services drop straight in.