Two Chrome windows, two accounts, at the same time

The usual reason for wanting two Chrome browsers with different accounts is not curiosity. It is a Google Doc that opens under the wrong login, a Slack notification that turns out to belong to the other company, or a client tool that signs the personal account out every time the work account signs in. Chrome can do this. The part that goes wrong is not the setup, it is the twenty times a day after the setup, when both windows look identical and nothing on screen says which one is which.

Profiles, accounts, and windows are three different things

Chrome has one concept that does the real work here, and it is the profile. A profile is a directory on disk that holds its own cookies, history, saved passwords, bookmarks, extensions, and signed-in state. Two profiles are, for practical purposes, two separate browsers that happen to share an application binary.

A Google account is not the same thing. Signing a second Google account into the same profile through the account switcher at the top right of Gmail gives one cookie jar with two identities in it. Sites that support Google's multi-login will offer both. Sites that do not, and there are many, will pick the first one and ignore the request. That is the source of the classic failure where a shared Drive link opens under the wrong identity and the fix is to copy the URL into a new tab with /u/1/ spliced into it.

Windows are the third thing, and they are the layer the reader actually interacts with. On macOS every Chrome window belongs to the same application, no matter which profile it belongs to. Command-Tab moves between applications, so it cannot move between profiles. Mission Control groups them together. The Dock shows one icon. This is why a profile split that is technically correct still feels wrong to use.

The setup problem is solved in five minutes. The window problem is what lasts.

Three ways to get two accounts open at once

Each of these works. They fail in different places, which is the useful part.

Approach	Separate cookies	Separate extensions	Distinct in the Dock	Survives a restart
Second Google account in one profile	No	No	No	Yes
Second Chrome profile	Yes	Yes	No	Yes
Incognito window	Yes	Mostly disabled	No	No
A second browser application	Yes	Yes	Yes	Yes
One window per web app	Yes	Yes	Yes	Yes

The account switcher is the fastest and the leakiest. Incognito is fine for a one-off login check and useless as a daily second account, because it forgets everything on close and most extensions are off by default. A second Chrome profile is the correct answer to the technical question. A different browser application, or a browser built to hold each app in its own window, is the answer to the ergonomic question.

Setting up the second profile properly

Open the profile chip at the top right of the Chrome window, choose to add a profile, and sign it into the second Google account. Two decisions during that flow matter more than they look.

The first is the name and the colour. Chrome shows the profile name in the chip and tints the window frame with the colour picked. Given that the two windows are otherwise identical, this tint is the only signal available at a glance. Pick colours that are far apart, not two shades of blue.

The second is whether to turn on Chrome sync for that profile. Sync is what carries bookmarks and passwords across machines, and it is also what will quietly pull the work profile's extensions onto a personal machine later. If the second profile exists to keep a client's tools sealed off, leaving sync off for it is the conservative choice.

Profiles live in ~/Library/Application Support/Google/Chrome/, in folders named Default, Profile 1, Profile 2, and so on. The folder name has nothing to do with the display name. The mapping between them sits in the Local State file in that same directory, under profile.info_cache. This matters for the next section, because scripts and shortcuts address the folder name, never the display name.

Launching a specific profile from the command line

Chrome on macOS does not offer a menu item that creates a desktop or Dock shortcut for one profile, the way the Windows build does. The equivalent is a launch flag.

open -na "/Applications/Google Chrome.app" --args --profile-directory="Profile 1"

The -n opens a new instance rather than raising the existing one, -a names the application, and everything after --args is handed to Chrome itself. Adding a URL after the flag opens that URL in that profile, which is the piece that makes the command genuinely useful. It can be wrapped in a small Automator application or a shell alias so that a work profile pointed at a specific dashboard is one action away.

Two cautions. Use the full path to the application. There are Chromium based wrappers on the market whose process name is also Google Chrome, and naming the app without a path can hand the command to the wrong one. And when Chrome is already running, some builds will ignore the profile flag and simply focus the window that already exists, which is why -n is in the command rather than optional.

Where the split quietly stops working

The failures are consistent enough to list.

Window identity is the first. Two profiles produce two windows with the same icon, the same shape, and the same position in Mission Control. The coloured frame helps until a screen has six windows on it.

Notifications are the second. A desktop notification from a site tells the reader that something happened, not which profile it happened in. Clicking it raises whichever window Chrome decides is right, and that decision is not always the one expected.

Link handling is the third, and it is the one that causes real errors. macOS sends a clicked link to the default browser, which delivers it to whichever Chrome window is frontmost. A calendar invite for the work account opens in the personal profile, the account does not have access, and the reader ends up requesting access to a document already owned by a colleague.

Memory is the fourth. Each profile runs its own set of extension processes, so two profiles with the same eight extensions installed run sixteen extension processes. On a laptop with other work open, that is noticeable.

What to do when a site refuses the second account

Some services never behave under a shared cookie jar, and knowing which ones they are saves a lot of guessing.

Google's own properties support multi-login, which is why Gmail and Drive can hold several identities at once. The identity is carried in the URL as /u/0/, /u/1/ and so on, numbered in the order the accounts were added rather than by any stable rule. That numbering is the reason a bookmark saved months ago starts opening the wrong mailbox after a third account is added. Bookmarks that point at /u/1/ are pointing at a position in a list, not at an account.

Most other services do not support it at all. Slack handles several workspaces inside one session but only one email identity per workspace. Notion switches between workspaces but keeps a single login. Figma, Linear, and most single sign on tools authenticate once per browser session and treat a second identity as a sign out followed by a sign in. For those, a second profile is not an optimisation. It is the only way to hold both open at the same time.

The practical test is simple. Open the service, add the second account through its own account menu, and reload the page. If the first account is still signed in afterwards, the service supports parallel sessions. If the first one is gone, that service needs a separate cookie jar, which means a separate profile or a separate window with its own session.

Anything that signs the first account out on a second sign in cannot be solved by habits. It needs a structural split.

When a second application beats a second profile

Once the second profile stops being an experiment and becomes a permanent part of the day, the deciding question changes. It is no longer whether the cookies are separate, because both approaches separate them. It is whether the operating system can tell the two apart.

An application, unlike a profile, gets its own Dock icon, its own place in Command-Tab, its own notification identity, and its own entry in the browser selection sheet. That is why some people simply keep a second browser installed for the second account. It works, at the cost of two engines updating, two sets of settings, and bookmarks that never quite line up.

The narrower version of the same idea is a browser that keeps each web app in its own window with its own session, so that Gmail for the work account and Gmail for the personal account are two addressable windows rather than two tabs behind the same icon. Sessions are held per app rather than per profile, which removes the multi-login problem at the root. The Workspaces page describes how a set of apps and accounts is grouped so that switching context moves everything at once, and the Supported apps list covers which services are set up to run that way out of the box.

Keeping the two identities from mixing

Whatever the structure, a few habits prevent most of the daily errors.

Give each profile a real name, not a colour name. "Client" and "Personal" survive a year. "Blue" does not.

Decide which profile owns links and set the default browser accordingly, then open the other one deliberately. Fighting the default is how invites end up in the wrong account.

Keep extensions asymmetric on purpose. Password managers, session tools, and anything that reads page content should exist in one profile and not the other, so that a mistake in one has a bounded blast radius.

Check the profile before typing credentials, not after. The chip at the top right is the only reliable indicator, and it takes a second to read.

Audit the split every few months. Profiles accumulate. A machine that has been through two jobs and three client projects tends to carry five profiles, two of which nobody has opened since last year, each still holding live sessions and saved passwords. Deleting a profile removes its folder and everything in it, so export any bookmarks worth keeping first, then remove the rest rather than leaving dormant logins on disk.

For a side by side view of how other tools in this category handle the same problem, Compared with Wavebox and Compared with Ferdium lay out the differences in session handling and platform support without pushing a conclusion.

What to change first

Start by creating the second profile properly and giving it a distinct colour and a real name, because that costs five minutes and removes the multi-login errors immediately. If the same context switch is still happening several times a day a week later, the problem is window identity rather than cookies, and moving each account into its own window is the change that fixes it. The pricing page for SpaceDeck is the place to check whether that route is worth the cost on a single Mac.