Give each Chrome profile its own shortcut on a Mac

Anyone searching for a Chrome profile shortcut on a Mac has usually already found the Windows instructions, followed them, and discovered that the menu item they describe does not exist in the macOS build. Chrome on Windows can create a desktop shortcut that opens one specific profile. Chrome on macOS cannot, and there is no hidden setting that turns it on. What exists instead is a launch flag, and everything useful is built on top of that one flag.

What the macOS build does and does not offer

The profile chip at the top right of a Chrome window opens a menu that can add a profile, switch to another one, open a guest window, and manage the whole set. It cannot produce a launcher. The Windows version of that same menu carries a shortcut creation item because Windows shortcuts are files that can carry arbitrary command line arguments. A macOS application in the Dock is a bundle, not a command line, so there is nothing for Chrome to write the profile name into.

The consequence is that every working solution on macOS falls into one of three shapes. A shell command that launches Chrome with a flag. A small application wrapper that runs that command when double clicked. Or a launcher tool that keeps the command as an entry and fires it from a keystroke.

None of them is fragile in itself. The fragile part is the profile identifier they all depend on, which is covered below.

There is no supported way to pin a profile to the Dock. Everything here is a wrapper around a command.

The command that actually launches a profile

The flag Chrome reads is --profile-directory, and it takes the folder name of the profile, not the display name shown in the interface.

open -na "/Applications/Google Chrome.app" --args --profile-directory="Profile 3"

Three details in that line matter.

The -n opens a new instance. Without it, when Chrome is already running, macOS raises the existing application and the arguments are discarded, so the command appears to do nothing.

The full path to the application is deliberate. Several products ship a Chromium based wrapper whose executable is also named Google Chrome, and passing the bare name lets the system resolve to one of those instead. Naming the path removes the ambiguity.

Everything after --args belongs to Chrome. A URL can be appended after the profile flag, and Chrome will open that page inside that profile. This is where the technique earns its keep, because the useful shortcut is rarely "open Chrome as the work account". It is "open the client dashboard as the work account".

Finding the right profile folder name

The display name and the folder name are unrelated. A profile shown as "Work" might live in a folder called Profile 5, and renaming the profile in the interface never renames the folder. Guessing is the single most common reason a shortcut opens the wrong account.

The folders sit in ~/Library/Application Support/Google/Chrome/. The first profile ever created is always Default. The rest are Profile 1, Profile 2, and so on, numbered in creation order, with gaps left behind when a profile is deleted.

The mapping is stored in the Local State file in that same folder, in a JSON object at profile.info_cache, where each key is a folder name and the value carries the display name and the signed-in email address. Reading that file is the reliable way to find the identifier. Opening a Chrome window and typing chrome://version into the address bar also works, since the profile path is printed there for whichever profile that window belongs to.

A shortcut built on a folder name that later gets deleted does not fail loudly. Chrome creates a fresh empty profile with that name and opens it, which looks like being signed out rather than like a broken shortcut.

Two flags worth knowing beyond the profile

The profile flag rarely travels alone in a launcher that gets used every day, because the point of the launcher is to land in a working state rather than on a new tab page.

Appending a URL after the profile flag is the first and most useful addition. open -na "/Applications/Google Chrome.app" --args --profile-directory="Profile 3" https://example.com opens that address inside that profile in one action. Several URLs can be listed, and each opens as its own tab, which turns a launcher into a morning setup rather than a browser opener.

The second is --new-window, which forces a new window rather than adding a tab to whatever is already open in that profile. Without it, a launcher fired while the profile already has a window will often add tabs to that window, which defeats the purpose when the intent was a clean second window on another screen.

A word of caution about the wider flag list. Chrome accepts a long set of command line switches, many of which are internal, undocumented for end users, and removed without notice between versions. Flags that disable security features or change how the profile directory is resolved can leave a browser in a state that looks fine and behaves subtly wrong. Sticking to the profile flag, a URL, and the window flag covers what a launcher needs and avoids that entire class of problem.

Turning the command into something clickable

Method	Effort to build	Own Dock icon	Own icon image	Breaks when
Shell alias or function	Minutes	No	No	Profile folder is deleted
Automator or Shortcuts app	Ten minutes	Yes	Yes, if set manually	Profile folder is deleted
Third party launcher entry	Minutes	No	No	Launcher is not running
A separate browser application	None	Yes	Yes	Nothing, but two engines to update

The Automator route is the one people usually settle on. Create an application, add a shell script action, put the open command in it, save it into the Applications folder, and drag it to the Dock. The saved application can be given a custom icon through the info panel, which finally makes the two profiles distinguishable on screen.

One detail catches people out on the first attempt. The Automator application will refuse to run, or run and do nothing visible, if the quoting in the shell action is wrong, and profile folder names contain a space. Keep the value in double quotes exactly as written above, and test the command in Terminal before saving it into an application, because a failing shell action inside Automator reports far less than the same command does in a terminal window.

The Shortcuts app can do the same thing with a Run Shell Script action and has the advantage of a keyboard trigger. Both approaches produce a launcher, not a container. The window that opens still belongs to Chrome, which leads directly to the limit described next.

Making the launcher survive a year

A shortcut built in ten minutes tends to break in ways that are hard to diagnose six months later, because nothing about the failure says "shortcut". Three habits prevent most of it.

Point the launcher at a URL, not just at the profile. A launcher named "Client dashboard" that opens the dashboard in the client profile is self documenting. A launcher named "Chrome Work" that opens a new tab page tells nobody, including its author, which profile it actually addresses.

Write the profile folder name in a comment inside the Automator script alongside the display name it corresponded to at the time. The folder name is opaque, the display name changes, and the two drift apart. One comment line removes an entire category of confusion later.

Do not delete profiles casually once launchers exist. Deleting Profile 2 does not renumber Profile 3, so surviving launchers keep working, but the deleted number is not reused either. A launcher pointed at the deleted one silently creates a fresh empty profile, which is the failure described earlier. Before removing a profile, search the Applications folder for launchers that mention it.

There is one more consideration for shared machines. Profile separation is a separation of stored logins, not a lock. Anyone sitting at the Mac can open the profile switcher and enter any profile on it, launcher or no launcher. If the goal is to keep a client's data away from another person rather than away from another tab, the split belongs at the macOS user account level instead.

A launcher makes the right profile easy to reach. It does not make the wrong one hard to reach.

The limit that no shortcut removes

A shortcut controls how a window opens. It does not change what that window is once it is open.

Every Chrome window on macOS belongs to one application. Command-Tab switches applications, so it cannot switch between the work profile and the personal profile. Mission Control shows them as siblings with the same icon. The Dock counts them as one item, no matter how many custom launchers were created to open them. Hiding Chrome hides all of them together.

Notifications inherit the same limitation. A message notification tells the reader that something arrived, not which profile it arrived in, and clicking it raises a window chosen by Chrome rather than by the profile the notification belongs to.

Link handling is the sharpest edge. macOS passes a clicked link to the default browser, which hands it to the frontmost Chrome window regardless of profile. A meeting invite for the work account lands in the personal profile, and the reader ends up requesting access to something already owned by a teammate. No launcher fixes this, because the launcher has already finished its job by then.

This is the point where the shortcut project stops paying off. Building the launcher is worth doing. Building three launchers, custom icons, and a keyboard layer to compensate for the operating system treating them all as one application is rebuilding, by hand, what a different browser shape gives directly.

When to stop scripting and change the shape

The deciding question is how often the switch happens. A profile opened twice a week is well served by a saved command. A profile switched between twenty times a day is a window management problem wearing a shortcut costume.

The alternative is a browser that treats each web app and each account as its own window with its own session, so the thing being switched to is addressable by the operating system rather than hidden inside one application. Command-Tab works again, notifications carry an identity, and the account is chosen by which window is open rather than by which flag was passed at launch. The Features page covers how the session isolation is arranged, and Workspaces covers grouping a set of accounts so that a whole context moves at once instead of one window at a time.

For readers weighing that against other products in the same category, Compared with Wavebox sets out the differences in platform support and session handling as plain facts rather than as a recommendation.

What to change first

Read the real folder name out of Local State or chrome://version before building anything, because a shortcut pointed at a guessed folder silently creates an empty profile instead of failing. Then build one Automator application for the profile used most, give it a distinct icon, and live with it for a week. If the friction that remains is switching rather than launching, the fix is a browser that gives each account its own window, and SpaceDeck is built around exactly that split.