How to use Chrome profiles so the split keeps working

Creating a profile takes about twenty seconds. Deciding what it is for takes longer, and skipping that decision is why a browser ends up with seven of them, three that are opened daily and four that exist because a client project needed a separate login eighteen months ago. Profiles are a good mechanism used badly more often than they are a bad mechanism. The difference is whether the set of them was designed once or accumulated one emergency at a time.

What a profile is capable of holding

Google's description of the feature is short and worth taking literally.

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

In practice that list covers cookies and logged-in sessions, bookmarks, history, saved passwords and autofill, installed extensions and their stored data, the default search engine, site permissions such as camera and notifications, and the set of tabs restored at launch. Each profile keeps its own copy of all of it in its own directory on disk.

That is a wide boundary, and it is the reason profiles are worth designing rather than improvising. A profile is not a view onto shared data. It is a complete second browser state that happens to run inside the same application, and everything put into it has to be maintained there separately for as long as it exists.

Choosing what one profile stands for

The most common mistake is splitting by task instead of by identity. A profile called Research or Reading has nothing that belongs to it. It holds no distinct login, and within a week it holds a mixture of everything.

The test that works is simple. A profile earns its existence when it needs its own logged-in state. If two contexts sign in to the same services with the same accounts, they belong in one profile no matter how different the work feels.

Split by	Works	Fails
Person sharing the Mac	Yes, this is the original design	Only if accounts are also shared
Account, such as work and personal	Yes, the most common good use	When one context needs both accounts at once
Client or organisation	Yes, when each has its own logins	When clients share the same tooling
Task, such as research or writing	Rarely	No distinct login, so nothing stays sorted
Environment, such as testing signed out	No	A private window does this without upkeep

Two or three profiles is a scheme. Six is a list to search through, and the time spent finding the right one starts to exceed the time saved by having the split at all.

Setting a profile up so it stays usable

Four settings, applied when the profile is created, prevent most of the friction that appears later.

Give it a short name rather than an email address. The switcher truncates, and two addresses at the same domain truncate to the same string. Give it a colour that is nothing like its neighbours, because colour is legible from the corner of the eye and an avatar initial is not.

Set the pages that open at launch to the ones that context actually starts from. A work profile that opens the work mail and the work board is immediately identifiable and saves the first two navigations of the day. Set the download folder per profile, in the downloads settings, so files arrive somewhere that says which context produced them. That last one is off by default, and it is the single change that turns a nominal separation into a real one.

Anything genuinely shared, such as a reference document used in both contexts, should be bookmarked in both. Trying to keep one canonical copy defeats the design, because bookmark lists never meet across profiles.

Extensions are installed per profile

An extension is installed into one profile and stored in that profile's directory. Putting the same extension in four profiles is four installations, with four separate permission grants, four sets of stored settings, and four copies running when four windows are open.

This has three consequences that show up over months. Memory use scales with profiles open rather than with extensions installed once. A permission granted in one profile does not apply in another, so an extension can appear to work in one window and do nothing in the next. And an extension that changes ownership or behaviour has to be reviewed in every profile it reached, not once.

The practical response is to keep the per profile list short and deliberate. A password manager usually belongs in every profile that signs in to anything. Everything else should be present only where it is used. Reviewing the list at chrome://extensions inside each profile once a quarter takes a few minutes and removes the accumulation that nobody notices happening.

What sync makes a profile worth on a second machine

Signing in to a profile with a Google account and enabling synchronisation makes that profile reproducible. Bookmarks, history, passwords, extensions, settings and open tabs can be pulled down onto another Mac by creating a profile and signing in with the same address.

What that does not do is turn sync into a backup with a restore point. It mirrors the current state. Deleting a bookmark on one machine deletes it on the other, and a profile removed locally does not remove the account data, which is why signing in again brings everything back and confuses people who expected a clean start.

The important boundary is between synced and local. Extension settings held by the extension itself, site permissions, and anything a page stored in local storage often stay on the machine. Anything that took real effort to configure and is not visible in the sync settings should be exported deliberately if it matters, since it exists in exactly one place.

Profiles at work are not entirely yours

When a profile is signed in to an account issued by an organisation, an administrator can set policy on it. That can include which extensions may be installed, whether synchronisation is allowed, whether other accounts can be added alongside the managed one, and whether the account is required to run in its own profile at all.

The visible marker is a note in the settings saying the value is managed. A setting in that state cannot be changed locally, and time spent trying is time lost. Reading chrome://policy in that profile lists what has been applied, which turns a vague sense that something is being blocked into a specific answer.

The corollary matters for anyone mixing contexts. A personal account added to a managed browser inherits the environment it is running in, including logging and extension restrictions where those apply to the browser rather than the account. Keeping a managed account in a profile of its own is less about secrecy than about not having personal browsing pass through a configuration set by someone else.

A three profile scheme, in full

An abstract rule is easier to apply against a concrete example, so here is one that survives normal use.

The first profile holds the employer account and nothing else. Its startup pages are the work inbox and the team board, its colour is strong and unambiguous, its downloads land in a folder named for the employer, and its extension list contains a password manager and whatever the job genuinely requires. It is signed in and synchronised, because a replacement machine has to be productive on the first morning.

The second holds the personal account. Same treatment, different colour, downloads into a separate folder, and a much shorter extension list. It is the profile that shopping, banking and personal mail live in, which is also why nothing experimental gets installed there.

The third is the disposable one. It is signed in to nothing, synchronises nothing, and exists for client portals, one-off registrations, and any service that has to be logged into once under an address that belongs to neither of the other two. Its bookmarks are treated as temporary. When it becomes cluttered, it is exported if anything matters, removed, and recreated in twenty seconds.

The shape of that scheme is what makes it hold. Two profiles carry identity and are maintained. One absorbs everything that would otherwise create a fourth, a fifth and a sixth. Most sprawl comes from treating every new login as a permanent context, and a single disposable profile is the cheapest way to stop that happening.

Nothing here depends on the specific job. Swap employer for main client and the same three slots work for freelance use, where the pressure to create a profile per client is strongest and the payoff is smallest.

How a working scheme rots

Profiles accumulate because creating one is the fastest answer to a temporary problem. A contractor login, a client portal that refuses to share a session, an event registration that had to happen under another address. Each of them is reasonable, and none of them get cleaned up.

The signs are recognisable. The switcher scrolls. Two profiles have names that no longer describe what is in them. One has not been opened in months but still holds the only copy of a bookmark folder that matters.

A short routine every few months is enough. Open each profile, check the extension list and the last used tabs, export bookmarks worth keeping from any profile due for removal, and then remove it. Removal is immediate and permanent for the local data, with no undo and no trash, so the export step is the whole job. Data that was synced returns with the account, and data that never synced does not.

Where the profile stops being the right unit

Profiles divide by identity. They do not divide by application, and that is the limit reached by anyone whose set of profiles is well organised and still not enough.

Inside a single profile, mail, chat, documents, an admin console and whatever else runs in a browser still compete for one tab strip in one window. Splitting accounts does nothing about that. Meanwhile every profile window looks like every other, carries the same dock icon, and appears as one application to the operating system, so switching between two profiles is not a normal application switch and cannot be treated as one.

The alternative model gives each application and account its own window and its own session, visible to the system as separate things. Switching becomes the same gesture used for any other app, and identification stops relying on a small avatar. That arrangement is described under Workspaces and in the feature set, and the differences against an open source tool in the same category are laid out in the comparison with Ferdium.

What to change first

Decide what each existing profile stands for and write it into its name, then set a per profile download folder and a distinct colour on each. That is under ten minutes and it converts a nominal split into one that holds. If the result is a tidy set of profiles that still needs constant switching, the unit that needs changing is the window rather than the profile, which is the ground SpaceDeck covers.