The Chrome default profile: why links keep opening there

A link arrives in Slack, it opens in Chrome, and it opens signed in as the wrong person. The work account was the one being used all morning, and yet the page appears in a window belonging to a personal profile, or in a profile that has not been touched in weeks. Nothing in Chrome's settings offers a switch labelled "open links here." That absence is the whole problem, and it is worth understanding before trying to fix it, because two different things are called the default profile and only one of them can be changed from a menu.

Two different things get called the default profile

The first meaning is literal. Every Chrome profile is a folder inside the user data directory, and the first profile ever created on a machine gets the folder name Default. Chromium's own documentation describes a profile as a subdirectory, often Default, within the user data directory. That folder name never changes. Renaming the profile in Chrome's interface changes a display name, not the directory.

The second meaning is behavioural: the profile that Chrome happens to open when something outside Chrome asks for a URL. This one has no fixed identity. It depends on which window was open, which profile was used last, and how the application was launched. Most searches for this phrase are really about the second meaning, while most answers found online describe the first.

Keeping the two apart matters because the fixes are different. A folder name is addressable, which means a launch can be aimed at it. A behaviour is not addressable, which means it can only be replaced by an explicit launch. Every workable solution below is a variation on the same move: stop letting Chrome choose, and name the profile at launch time.

Where profiles live on macOS, and how to identify the one in use

On macOS the user data directory sits at ~/Library/Application Support/Google/Chrome. Inside it, the folders are named Default, Profile 1, Profile 2, and so on, in creation order. The name shown in Chrome's profile picker is stored separately, which is why a profile displayed as "Work" can live in a folder called Profile 3.

To find out which folder the current window belongs to, open chrome://version and read the Profile Path row. It prints the full path, ending in the folder name. The User Data Dir row above it prints the parent. Chromium's documentation points to the same page for exactly this purpose. Doing this once per profile and writing down the mapping takes about two minutes, and every later step depends on having it.

The mapping is not cosmetic trivia. The creation order that produced Profile 1 and Profile 2 is invisible in the interface, so guessing is easy and wrong. A launch aimed at Profile 1 because it sounds like the first extra profile will open whichever profile happened to be created second overall, which may well be the one that was abandoned after a week.

Why the operating system cannot send a link to a specific profile

macOS registers a default browser at the application level. The setting in System Settings names an app, and the app receives the URL. There is no mechanism in that setting for naming something inside the app, because as far as the operating system is concerned Chrome is one application with one entry point.

So the URL arrives at Chrome, and the choice of profile happens inside Chrome, where it is not exposed as a preference. This is the structural reason the problem resists configuration. Nothing is broken and nothing is misconfigured. There is simply no setting in either place that expresses the desired rule, which is "links from work apps belong to the work profile."

Two consequences follow. First, any solution has to bypass the generic launch, either by launching Chrome with an explicit profile or by putting something else in the default browser slot. Second, no amount of renaming profiles, reordering them, or signing out and back in will change the outcome, because none of those touch the launch path.

Three ways to pin a launch to a chosen profile

Chrome accepts a --profile-directory switch that names the folder to open. Combined with the macOS open command, that produces a launch aimed at one profile:

open -na "Google Chrome" --args --profile-directory="Profile 3"

The value is the folder name from chrome://version, quoted because of the space. Saved as a shell alias, or wrapped in a small application, this becomes a per-profile launcher that behaves like a separate app in the Dock.

The second approach is the profile picker. Chrome's help documents a "Show on startup" checkbox, reached by selecting Profile at the top right, then Manage Chrome profile. With it enabled, every new browser session begins with a chooser rather than a guess. It costs one click each time and removes the class of error where a page opens signed in as the wrong account without anyone noticing.

The third approach is to stop sending links to Chrome at all, and register a different application as the default browser. Several small utilities exist for this, and the app aggregation browsers do it as a side effect of keeping each service in its own window.

Approach	What it fixes	What it costs
--profile-directory launcher	Launching from the Dock or a script always lands in a known profile	Does not govern links handed over by other apps
Profile picker on startup	Removes silent wrong-profile sessions	One click per launch, and no effect on links
Different default browser app	Governs links handed over by other apps	A new tool in the chain, and a migration

The table makes the shape of the problem visible. The first two govern launches that start from the person. The third is the only one that governs links arriving from elsewhere, which is where the original complaint usually comes from.

What none of this fixes

Pinning the launch does not separate the accounts inside a profile. A profile signed into three Google accounts still resolves a Google Docs link against whichever account is first in that profile's list, and the wrong document opens even though the right profile did. Profiles separate storage, not identity within storage.

Extensions stay per profile as well, which is deliberate and occasionally painful. A launcher that opens Profile 3 opens Profile 3 with whatever extensions it has, so a password manager installed only in Default is missing, and installing it everywhere multiplies the surface that has to be trusted and updated.

Then there is the window problem, which no launch flag addresses. Once several profiles are open, the Dock shows one Chrome icon and the window list mixes them together. The profile colour and avatar help at a glance, and they stop helping around the point where six windows are open across three profiles. This is the point at which people start looking past profiles entirely, at tools that give each service its own window and its own session. The design is described in Workspaces, and what that separation covers in practice is listed in Features.

Deleting and renaming: what actually gets destroyed

Renaming is safe. The name, photo, and colour are display attributes, and Chrome's help describes changing them from Manage Chrome profiles. The folder name underneath is untouched, so any launcher written against Profile 3 keeps working.

Deleting is not safe, and the help is explicit: removing a profile from Chrome deletes that profile's bookmarks, history, passwords, and other settings from the computer. Data that was synced to a Google account can be recovered by signing in again on a fresh profile. Anything that lived only locally is gone. Before deleting a profile that has been used, exporting its bookmarks to an HTML file from the bookmark manager takes under a minute and covers the most commonly missed item.

A related trap: tidying up by deleting the profile in the folder named Default does not promote another profile to that name. The folder is simply absent, and a launcher aimed at it creates a new empty profile there, which then looks like the original one came back blank.

Checking that a launcher actually opened the right profile

A launcher that silently fails is worse than no launcher, because it restores the original confusion while looking solved. The check is short. Run the command, then open chrome://version in the window that appears and read the Profile Path row. If it ends in the folder that was named in the switch, the launch worked.

Two failure modes account for most surprises. The first is a running instance. If Chrome is already open, a launch without the -n flag can hand the request to the existing process, which opens a window in whatever profile that process considers current, ignoring the switch entirely. Using open -na asks for a new instance and avoids that path. The second is a folder name that does not exist. A switch pointing at Profile 4 on a machine that only has three profiles does not fail loudly. Chrome creates a new, empty profile with that folder name, and the result looks like a profile that lost all of its data.

Because of the second behaviour, it is worth verifying folder names by reading them rather than predicting them. A profile created and then deleted leaves a gap in the numbering, so the highest number in the folder listing is not a reliable count of the profiles that exist today.

Keeping the mapping accurate as profiles come and go

The folder-to-name mapping drifts, because every new profile takes the next unused number rather than a name related to its purpose. Adding a profile for a client project six months from now produces Profile 6, and nothing in the interface records why. A short note kept alongside the launchers, listing folder name, display name, and which accounts are signed into it, is enough to keep the set usable.

Three habits keep the drift small. Create profiles deliberately rather than accepting the one Chrome offers when a second account signs in, since the automatic path is how machines end up with profiles nobody can identify. Re-check the mapping after deleting anything, because deletion leaves gaps and the remaining folders keep their numbers. And when a launcher stops landing where expected, read chrome://version before rebuilding it, since the usual cause is a mapping that moved rather than a command that broke.

None of this scales indefinitely. Past roughly four or five profiles the bookkeeping starts to cost more than the separation returns, which is the point where per-service windows become the cheaper structure. The trade between the two approaches is laid out in Compared with Wavebox.

What to change first

Open chrome://version in each profile, note the Profile Path, and write down which display name maps to which folder. With that mapping in hand, build one launcher per profile with --profile-directory and use those instead of the generic Chrome icon, which removes wrong-profile launches without changing anything else. If the remaining pain is links handed over by other applications, that is a default browser question rather than a profile question, and worth comparing against a tool that keeps each service in its own window, such as SpaceDeck.