Chromeのプロファイル: how to decide what you need

Most people approach Chrome profiles by asking how many to create. That question has no stable answer, because the number changes every time a new account or a new client appears. The answer that does stay stable is the boundary: the rule that decides what goes in a separate profile and what does not. Once the boundary is chosen, the count follows from it, and so does the decision about every account added later. What follows is a way to pick that boundary, three tests for whether a given profile is worth creating, and the limits that no amount of profile management will fix.

The boundary decides how the set grows

There are three boundaries in common use, and the meaningful difference between them is not tidiness. It is growth rate.

Boundary by person. One Mac shared with a partner, a family member, or a colleague, where the point is that the other person does not see this browsing history. This boundary does not grow. The number of people sharing the machine is fixed and small.

Boundary by identity. A work account and a personal account on the same services, both signed in at the same time. This boundary usually stops at two, occasionally three.

Boundary by counterparty. A separate Google Workspace or client account for each organisation being worked with. This one grows, and it grows on a schedule nobody controls. Every new contract adds a profile, and finished contracts rarely get cleaned up.

Google's own documentation describes the first two cases and stops there. Profiles are presented as suitable when a computer is shared with several people, or when different accounts such as work and personal are kept apart. The third case, one identity per client, is the one that produces a picker with nine entries by the end of a year.

Picking a boundary is therefore a decision about maintenance, not about neatness. A boundary that does not grow can be set once and forgotten. A boundary that grows needs a rule for what happens when a client relationship ends, decided now rather than during the eventual cleanup.

Three tests for whether a profile earns its place

Once candidates are listed under the chosen boundary, each one gets three questions. A candidate that fails all three does not need a profile, and creating one anyway adds cost with no return.

Test	If yes	If no, the substitute
Two accounts on one service must stay signed in simultaneously	Create the profile	One profile, sign in and out
The set of extensions differs between the two contexts	Create the profile	Toggle extensions per session
Confusing the two would cause real damage	Create the profile	Change the bookmarks bar instead

The first test carries the most weight, and it is the only one with a hard technical basis. A profile holds exactly one cookie store, so one profile cannot hold two live sessions on the same domain. Nothing else in the browser works around this. If the answer here is yes, the remaining tests do not need to be asked.

The second test gets skipped more often than it should. Extensions install per profile and keep their settings per profile, which matters when one context uses a tool with broad permissions, such as one that reads page contents. Keeping that tool out of personal browsing is a legitimate reason to separate. The reverse is also true: if both contexts run the same five extensions, this test provides no reason at all.

The third test is about consequences rather than convenience. Running the wrong command in a client's production console is not the same class of mistake as reading personal email in a work window. When the damage from a mix-up is recoverable, a distinct theme colour usually handles it. When it is not recoverable, separation is warranted.

What a profile does not separate

Four things stay shared no matter how the profiles are arranged, and each one is a common source of the feeling that profiles are not working.

Link handling. macOS has one default browser per application, not per profile. A link clicked in a mail client or a chat app lands in whichever Chrome window was most recently used. There is no way to route a link to a specific identity at the moment of the click, which is where most misdirected clicks come from.

Application switching. The Dock holds one Chrome icon. The application switcher moves between applications, so it cannot move between profiles. Getting to a specific profile means cycling through the windows of one application, and that cycle gets longer with every profile added.

Extensions, when the same account is used. Extensions are per profile, but signing two profiles into the same Google Account brings the same extensions back through sync. Separating extensions requires separate accounts, or one profile left signed out.

Access. The profile picker asks for nothing. Google states plainly that anyone with the device can switch to any other Chrome profile on it, and see the sites that profile visited. Profiles are organisation, not a lock. When someone must genuinely be kept out, the tool is a second macOS user account.

That last point changes the answer for shared machines specifically. A profile on a shared Mac creates the appearance of privacy without providing it.

Naming and colour, decided once

Naming looks trivial and turns out to matter, because a name is read every time the picker opens. The rule that holds up is to put only the boundary term in the name. If the boundary is by counterparty, the name is the organisation. If it is by identity, the name is the purpose. Dates, version numbers, and words like "new" or "temporary" stop meaning anything within a quarter, and then the picker requires interpretation rather than reading.

Colour is best assigned by consequence rather than by frequency. The profile where a mistake is expensive gets the loud colour, and the read-only profile gets something quiet. The theme colour appears in the band at the top of the window, which is what the eye actually catches when windows are stacked. Avatars and photos are available, but at macOS window sizes they compete for attention with everything else in the toolbar, so treating colour as primary and the avatar as secondary keeps the decision simple.

The practical limit is the palette. Chrome offers a fixed set of theme colours, so beyond roughly half a dozen profiles, similar colours start appearing next to each other and the visual signal weakens. That limit is worth knowing before choosing a boundary that grows.

Accounts issued by an organisation

A profile signed into an account issued by an employer or a client is not fully under the control of the person using it. Administrators can push policies to managed profiles, covering which extensions may be installed, whether sync can be enabled, and how browsing data is handled. Whatever the boundary chosen, these profiles sit inside it on different terms.

The practical consequence is that a managed account should not share a profile with personal data. Signing an organisation's account into a profile that also holds personal bookmarks puts that whole profile within reach of policy. Keeping the managed account in its own profile is less about preference than about knowing where the administered area starts and stops.

Typing chrome://policy into the address bar lists everything currently applied. Settings that will not change, greyed out controls, and extensions that refuse to install usually have their explanation on that page rather than in a broken profile.

Two counts that settle the question

The decision reduces to two numbers, and both can be produced in a few minutes without any tooling.

The first is the depth of account overlap, which is not the same as the number of services in use. Count only the services where more than one account has to be reachable. If mail has a work address and a personal address, a notes tool has one account, and a chat tool has three client workspaces, the overlaps are two and three. The minimum number of profiles is the largest of those overlaps, because that is the point where one cookie store cannot cover the requirement. Three client workspaces on one chat service means three profiles, regardless of how the rest is arranged. Where no overlap exists anywhere, the minimum is one, and any additional profile has to justify itself through the second or third test rather than through sign-in.

The second number is how often a working day crosses a boundary. Contexts that change once around midday behave very differently from contexts that alternate every few minutes. At a low crossing rate, even a heavy separation such as a second macOS user account is comfortable, because the cost is paid twice a day. At a high rate, the cost is paid dozens of times, and the thing being optimised stops being separation and becomes the transition itself.

Crossing frequency	Unit that fits	Reason
Around once per half day	macOS user accounts	Strong separation, paid for rarely
Several times per day	Chrome profiles	A few clicks per switch, separation intact
Many times per hour	A fixed window per app	Removes the switch instead of speeding it up

With both numbers written down, the overlap sets the count and the crossing rate sets the unit. Cases that still feel undecided are usually cases where the counting has not actually been done.

When the unit itself is the wrong choice

Everything above assumes the unit of separation is the identity. There is a second option: make the unit the application, with one window permanently assigned to each web app, so identity follows from location rather than from a choice made at the picker.

The difference shows up in how often boundaries get crossed. A workflow where morning and afternoon are different contexts crosses rarely, and a picker is fine. A workflow that moves between mail, chat, and a client console several times an hour turns the act of switching into part of the job, and the failure mode becomes mis-clicks rather than slow clicks. Making switching faster increases the number of switches without reducing the errors.

Tools built on the per application unit exist for macOS. The window model is described on Workspaces, and how it differs from a standard browser on Features. Whether specific services are supported is listed under Supported apps, and the cost is on Pricing. For a direct comparison against existing products in this category, Compared with Wavebox and Compared with Rambox cover the differences, and remaining behavioural questions are answered in the FAQ.

What to change first

Count the services where two accounts must be signed in at the same time, and count how often a working day crosses between contexts. The first number is the minimum profile count; the second decides whether the picker is the right unit at all. If the second number is high, the next thing to evaluate is SpaceDeck rather than another profile.