Chromeのプロファイル: what it does and where it breaks down

A profile is described in the Chrome interface as a way to keep things separate, and that description is accurate as far as it goes. The trouble starts where it stops. Separation inside a browser has an edge, and almost every complaint about profiles on a Mac turns out to be something crossing that edge: a download landing in the wrong place, a link opening in the wrong window, a notification that gives no clue which account it belongs to. Knowing where the edge sits is what makes profiles useful, because it tells you which problems they will never solve no matter how many are created.

The state a profile takes responsibility for

Google describes the purpose in its help documentation for managing Chrome with multiple profiles:

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

In practice the list is longer than that sentence and it is worth having in full, because each item is a thing that will not leak between profiles.

• Cookies and site storage, which is what holds a login open. This is the item that matters most and the reason profiles exist.
• Saved passwords and autofill data, including addresses and payment methods.
• Browsing history, along with the address bar suggestions built from it.
• Bookmarks and the bookmark bar.
• Installed extensions, their configuration and the permissions granted to them.
• Site permissions: camera, microphone, notifications, location.
• The default search engine, the startup pages and the theme.

Because cookies live in the profile rather than in the tab, two profiles can hold two live sessions on the same domain at the same moment. Two Gmail accounts, two Slack workspaces, two accounts on the same admin console, all signed in simultaneously with no interference. No amount of tab arrangement achieves that, and it is the one thing a profile does that nothing else in the browser can do.

That is the whole of the guarantee. Everything below this line is outside it.

What stays shared, and why the gap matters

The boundary is drawn around browser state. Anything that belongs to the operating system, the network or the file system sits outside and is common to every profile on the machine.

Downloads go to one folder. A contract pulled from a client account and a photo saved from a personal one land side by side in the same directory, with nothing recorded in the file to say which session fetched it. Each profile does have its own download location setting, so this is fixable, but it is off by default and the default is what most people run.

The network connection is shared. Every profile leaves the Mac through the same interface and presents the same public address. Anything a site infers from that address, including country and organisation, is identical across profiles. The same applies to screen dimensions, operating system version, installed fonts and the other traits that fingerprinting uses. Two profiles are two sets of cookies, not two identities.

Access is shared as well, and Google states it directly rather than leaving it implied:

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

There is no password on a profile. Switching takes two clicks and no credential is asked for. That makes a profile an organisational boundary rather than a security one, and treating it as the latter is the single most expensive misunderstanding in this area.

State	Separated per profile	Shared across every profile
Cookies and site sessions	Yes
Passwords, autofill, history, bookmarks	Yes
Extensions and their settings	Yes
Site permissions	Yes
Download destination	Configurable, shared by default
Public address and device fingerprint		Yes
Access to the profile itself		Yes, no password required
Which profile an external link opens in		Yes, one setting for the whole browser

An Incognito window is not a lighter profile

The two get treated as versions of the same idea and they sit on opposite sides of the boundary. An Incognito window does hold its own cookie jar, so a second account can be signed in there without disturbing the first. It keeps nothing afterwards. Closing the last Incognito window discards the cookies, the history and the site storage, which means tomorrow starts with a login screen again.

Extensions are off in Incognito unless each one is explicitly allowed, downloads still land in the shared folder, and the public address is the same as everywhere else. The useful distinction is duration rather than strength: Incognito is a session that is meant to end, a profile is a session that is meant to persist. Reaching for Incognito to solve a daily second account problem produces a login screen every morning, and reaching for a profile to browse something once leaves a folder on the disk forever.

Where an external link lands

This is the failure that recurs most often, because it happens several times a day and nothing about it is obvious.

A link arrives in Slack, in Apple Mail, in a calendar invitation. macOS hands it to the default browser, the default browser is Chrome, and Chrome puts it in whichever window was most recently in front. There is no rule that sends a work domain to the work profile. The operating system knows about one application called Chrome and nothing about the profiles inside it.

The result is a document opening in a window signed into the wrong account, followed by a permission wall, followed by copying the address, switching profiles, and pasting it into the right window. That round trip takes under a minute and it happens again an hour later.

There are partial mitigations. Keeping only one profile open at a time makes the destination predictable, at the cost of losing everything the other profiles had on screen. Third party link routers sit between the system and the browser and dispatch by domain, which works but adds a component to maintain. The structural answer is different: tools that keep each web application in its own persistent window do not have a most recent window to guess at, because each application already has a fixed place, an arrangement described on the features page.

Notifications lose track of which account they came from

Web notifications are granted per profile, which sounds like the right design and produces a confusing result at the system level.

macOS receives the notification from an application called Google Chrome. The banner shows the site name and the message. It does not show which profile raised it, because that concept does not exist outside the browser. Two Slack workspaces in two profiles produce two identical looking banners, and clicking one brings forward whichever Chrome window the system associates with it, which is frequently not the one where that message lives.

The Notification Centre stacking makes this worse rather than better, since all Chrome notifications collapse into a single group. Muting notifications for Chrome in System Settings mutes them for every profile at once, which is rarely what anyone wants: the usual goal is silence from the personal account during work hours and nothing more.

The practical workaround is to grant notification permission in exactly one profile per service and deny it elsewhere, so that at least the source of a banner is unambiguous. That takes a pass through site settings in each profile and it holds until a new service is added.

Profiles multiply windows, and macOS counts windows

Switching profiles does not change the contents of the current window. It opens another one and leaves the first where it was. After a normal morning there are four Chrome windows open, and the Mac treats them as one application with four windows.

That matters because the standard ways of moving around macOS stop being useful at that point. The application switcher shows a single Chrome icon regardless of how many profiles are running. Cycling between windows of the front application steps through all of them in an order that has nothing to do with which account is which. Mission Control shows four near identical rectangles of tabs. Assigning a window to a desktop helps until Chrome is restarted and the windows come back in a different arrangement.

The profile picture in the corner of each window is the only visual marker, and it is roughly twenty pixels across. Setting a strong theme colour per profile is the cheapest improvement available here, since it turns identification into something peripheral vision can do. That takes thirty seconds per profile and it is the highest return adjustment in this entire article.

Deletion is the one action without an undo

Google flags this in the same help page, and the wording leaves nothing ambiguous:

Important: After you remove a profile from Chrome, the profile's bookmarks, history, passwords, and other settings are erased from the computer. Source: support.google.com

Anything that was syncing to a Google Account survives in the account and comes back when a new profile signs into it. Anything that was not syncing is gone: local bookmarks in a profile that was never signed in, passwords saved before sync was enabled, extension data that the extension kept locally rather than in its own cloud account.

The profile removal dialog does not itemise what is about to disappear. Before deleting anything, open the profile, export the bookmarks to a file, check whether the password manager in use stores its vault locally, and confirm that sync is actually on rather than merely signed in. Those two states look almost identical in the Chrome settings screen and only one of them protects the data.

Separating by role rather than by person

Most profile setups start as one per human identity: work, personal, perhaps a second client. That mapping is intuitive and it is where the trouble accumulates, because a single person moves between roles many times an hour while identities are supposed to stay put.

The alternative is to separate by what the window is for rather than by whose account it holds. A window that exists for communication. A window that exists for administrative consoles. A window that exists for reading. Sessions still need to stay apart, but the unit of switching becomes the task, and tasks change far less often during a day than accounts do.

Chrome cannot express that directly, because its only unit is the profile and every profile is a full browser. Tools built for this problem give each web application a fixed home and let several accounts coexist inside one layout, which is the arrangement set out on the workspaces page.

What to change first

Set a distinct theme colour on every profile today, and turn off notification permission for any service that is granted it in more than one profile. Then watch for a week where the crossings happen: if the recurring cost is links landing in the wrong window rather than sessions colliding, the problem is outside the boundary a profile draws, and something like SpaceDeck is aimed at that outside.