How to Open Links in a Specific Chrome Profile on Mac

Why does Chrome open links in the wrong profile?

Because macOS and Chrome disagree about the unit of identity. To macOS, Chrome is one application with one bundle identifier — com.google.Chrome — and Launch Services routes http and https links to that bundle. Profiles are invisible at that layer; the system has no vocabulary for them.

Chrome then decides which of its windows gets the URL, and its rule is rarely what you want: the link goes to the most recently focused profile window, or, if Chrome is closed, to the profile active when it quit. Which profile a link opens in is decided by what you were reading five minutes ago.

• Personal window focused last → the work link opens in personal.
• Chrome closed with the work profile active → personal links open in work.
• Windows open across several profiles → the most recently clicked wins.

How do you find your Chrome profile folder names?

This is the step that trips people up. The names in Chrome's profile switcher are display labels stored inside Chrome. The folders on disk are numbered in creation order and never renamed, so the profile you call 'Work' may be the directory 'Profile 2'. Every command below needs the folder name.

Two ways to map labels to folders. Quick: open the window whose profile you want, go to chrome://version, and read the Profile Path row — it ends in the folder name. Complete: Chrome keeps the mapping in ~/Library/Application Support/Google/Chrome/Local State, under profile.info_cache, where each key is a folder name and each entry's 'name' field is the label.

• List every profile at once: jq '.profile.info_cache | to_entries | map({folder: .key, name: .value.name})' ~/Library/Application\ Support/Google/Chrome/Local\ State
• Or open the Chrome window you care about and read Profile Path at chrome://version.

How do you open a link in a specific Chrome profile from the command line?

Use the --profile-directory flag with the folder name, calling the Chrome binary directly. That detail matters: 'open -a' passes arguments only when it launches a new process, so with Chrome already running the flag is silently dropped and you are back to last-focused-window behaviour. Invoking the executable inside the bundle forwards the request with the profile intact:

• '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome' --profile-directory='Profile 1' https://example.com
• '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome' --profile-directory='Default' https://example.com
• Append & to get your shell prompt back immediately.

A shell function per profile makes this liveable, and the same command is what a Shortcuts 'Run Shell Script' action or a Raycast script calls under the hood. It composes with the other command-line link tricks.

Can you set a Chrome profile as the default browser?

No, and it is worth understanding why, because a lot of time gets lost trying. macOS stores the default handler for http and https as a bundle identifier — a single app. A profile is not an app: no bundle, no Info.plist, no identifier. There is nothing for Launch Services to point at, so the dropdown could not list profiles even in principle.

The usual workaround is a tiny wrapper app — AppleScript or Automator running the --profile-directory command — which works for launching. Making that wrapper the system default is harder: an app only appears in the dropdown if its Info.plist declares it a handler for the http and https schemes, which means editing the bundle by hand and re-registering it. Workable, but a lot of maintenance for a routing rule.

• Chrome's 'Set as default browser' button sets Chrome, never one profile.
• Chrome's Create Shortcut feature makes site-specific apps, not link handlers.
• The last profile you looked at wins unless something passes the flag explicitly.

How do you route links to the right Chrome profile automatically?

Put a router in front of Chrome. A picker registers as the single macOS default browser — the thing Launch Services *can* point at — receives every link, and launches Chrome with the correct --profile-directory flag. From Chrome's side it is an ordinary flagged launch; from yours, the link lands in the right profile.

With a browser picker like Hoplink, each Chrome profile appears as its own entry alongside Safari and Firefox, so choosing 'Chrome — Work' is the same gesture as choosing any browser. Hold Option and that profile becomes the permanent rule for the current site; hold Option and Shift and it becomes the rule for the app the link came from.

1. Map labels to folder names once at chrome://version.
2. Set the picker as the default browser in System Settings › Desktop & Dock.
3. Click a work link and Option-click the work profile — that domain is now bound.
4. Option-Shift-click the same profile from a Slack link to bind the whole app, as in the Slack fix.
5. Command-Shift-Z on the toast undoes a route that went to the wrong profile.

A handful of rules covers the realistic cases: company domain and internal tools to the work profile, personal mail and shopping to the personal one, everything else left to ask. That makes profiles behave the way people assumed they already did — and it is the piece that makes keeping work and personal browsing separate hold up over months.

Do Firefox and Edge have the same problem?

Edge does, identically — it is Chromium, takes the same --profile-directory flag, and keeps the same Local State structure at ~/Library/Application Support/Microsoft Edge.

Firefox differs. Its profiles are selected with -P 'name' or --profile /path/to/profile, using the name you chose rather than a numbered folder, and you can inspect them at about:profiles. Firefox also has Container Tabs, which isolate cookies *within* one profile — but containers are not addressable from outside Firefox, so an incoming link cannot be aimed at one. For external links, separate profiles remain the mechanism.

Frequently asked questions