Pin a Chrome profile to the Dock and open it directly

Three Chrome profiles. One Dock icon. Clicking it opens whichever profile happened to be in front when Chrome last quit, and reaching the right one means going through the avatar button, waiting for a second window to appear, then closing the window that opened by mistake. Windows users get a checkbox that puts each profile on the desktop as its own shortcut. macOS has no equivalent, which is why searching for how to add a Chrome profile to the Mac Dock returns a lot of advice that quietly assumes the wrong operating system.

There is a way to do it on a Mac. The result is a launcher rather than a second copy of Chrome, and knowing that difference in advance is what decides whether the setup is worth building.

Why one Chrome icon covers every profile

The Dock pins applications, and an application on macOS is a bundle. Google Chrome is a single bundle at /Applications/Google Chrome.app with a single bundle identifier, com.google.Chrome. Every profile window comes out of that one bundle, so the Dock has exactly one thing to show.

A Chrome profile is not an application. It is a directory under ~/Library/Application Support/Google/Chrome that holds its own cookies, extensions, history, autofill entries, saved passwords and settings, while sharing the executable, the process family and the identity that macOS uses for the Dock, the Cmd+Tab switcher and Notification Center. Two profiles are isolated from each other in terms of data. They are not isolated at all in terms of how the operating system sees them.

That is also why the Windows advice does not port. On Windows, Chrome writes a shortcut file carrying the --profile-directory flag, and the taskbar is happy to pin a shortcut file. The macOS Dock does not pin command lines. It pins bundles. So every workaround below is the same move underneath: build something macOS accepts as an application, and have that thing start Chrome with the right flag.

One consequence is worth stating before any setup work: none of these approaches splits Cmd+Tab for the profiles inside Chrome. Windows belonging to three profiles remain three windows of one application, and the keyboard switcher will keep treating them that way.

Find the folder name before anything else

The flag takes the directory name, not the label shown in the Chrome interface. A profile displayed as "Work" can live in a folder called Profile 17. Getting this wrong is the most common reason a launcher silently opens the wrong account.

There are two reliable ways to read it. Open a window in the profile you want, go to chrome://version, and look at the Profile Path line, which ends in the folder name. Or read the mapping directly out of the Local State file, which is the JSON index Chrome keeps of every profile on the machine:

python3 -c "import json,os;d=json.load(open(os.path.expanduser('~/Library/Application Support/Google/Chrome/Local State')))['profile']['info_cache'];[print(k,'->',v.get('name')) for k,v in d.items()]"

Two things surprise people here. The first profile ever created is not Profile 0, it is Default. And the numbering has gaps, because deleted profiles do not renumber the survivors. On a machine that has gained and lost accounts over several years, the list can jump straight from Profile 1 to Profile 17. Copy the folder name exactly as printed, including the space, and keep it in quotes when it reaches a shell.

Four ways to put a profile on the Dock

Approach	Own Dock icon	Own Cmd+Tab entry	Keeps the existing profile	Setup effort
Automator launcher app	Yes	No	Yes	About ten minutes
Install page as app	Yes	Yes	Yes, bound to the installing profile	About one minute, per site
Second Chrome release channel	Yes	Yes	No, separate data store	A download plus sign-in
Browser built around separate windows	Yes	Yes	No, sign-in again	Varies

An Automator application that runs the open command

This is the closest thing to the Windows behaviour. A tiny application does nothing but call open with the profile flag, and that application is what sits in the Dock. It is free, it uses the profile already on the machine, and it survives Chrome updates because it only ever references the bundle path. Its weakness is that it quits as soon as it has launched Chrome, so the Dock icon bounces and disappears rather than staying lit while the windows are open.

An app installed from a single page

Chrome can turn one site into a standalone application. The menu wording has changed across versions, so look under the three dot menu for the group containing Cast, save and share, then the option to install the page as an app. The result lands in ~/Applications/Chrome Apps.localized as a real bundle with its own Dock icon and its own Cmd+Tab slot, and it runs in the profile that installed it.

This is per site rather than per profile, which is a limitation if the goal was a general browser window, and an advantage if what the reader actually wanted was the work Gmail account sitting in its own window all day. The catch is that the installed app inherits the profile silently. Installing the same site twice from two different profiles produces two apps with the same name and the same favicon, and nothing in the Dock distinguishes them, so rename them in Finder immediately after installing rather than a week later.

A second Chrome release channel

Chrome Beta and Chrome Canary install as separate bundles with separate data directories, so they behave as genuinely separate applications: separate Dock icons, separate Cmd+Tab entries, separate notification identity. The cost is a second browser to keep updated, a fresh sign-in, and pre-release code on an account that may be the one that matters most. Some people use it for the personal account and keep stable Chrome for work, which keeps the risk on the less critical side.

A browser built around separate windows

The last option changes the unit of organisation. Instead of one browser holding many profiles, each web app gets its own window, its own icon and its own place in the switcher. That is a bigger change than a launcher and is only worth it if the real complaint was never about launching.

Build the launcher, step by step

Open Automator, create a new document, and choose Application rather than Workflow. Search the action list for Run Shell Script and drag it into the empty pane. Set the shell to /bin/zsh, delete the sample text, and paste one line, replacing the folder name with the one read out earlier:

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

Save it into /Applications with a name that says which account it opens, such as Chrome Work. To give it a recognisable icon, copy any image to the clipboard, select the saved application in Finder, choose Get Info from the File menu, click the small icon at the top left corner of the Info window so that it gains a highlight, and paste. Then drag the application into the left section of the Dock, the side reserved for applications. Building a second one for another account takes about a minute, since the only thing that changes is the folder name in the command and the name of the saved file.

The -n is the part that people leave out and then report as broken:

-n Open a new instance of the application(s) even if one is already running.

Source: the macOS open(1) manual page

Without it, when Chrome is already running, the request is handed to the existing process and the arguments after --args are dropped. The command appears to work, and quietly opens another window of whatever profile was already in front. Adding a URL to the end of the same line opens that page in the chosen profile, which turns the launcher into a one click route to a specific dashboard rather than a blank tab.

What the launcher does not fix

It fixes launching. It does not fix switching, and those are different problems that feel similar from the inside.

Once the windows are open, everything reverts to normal Chrome behaviour. Cmd+Tab still shows one Chrome. Mission Control mixes windows from every profile into the same group. Notifications from every account are attributed to Chrome, so a badge on the Dock says only that something happened somewhere. If Chrome is set to continue where it left off, the first launch of the day can restore windows from several profiles at once, and the flag only governs the new window it was asked to open.

A useful test before investing the ten minutes: over one working day, count how often the action is launching a browser that was closed, and how often it is finding a window that is already open behind six others. Most people who keep Gmail, Slack, Notion and a project tracker open all day launch the browser once in the morning and then hunt for windows for the rest of the day. If the second number is much larger, a Dock launcher will not move it, and the honest answer is that the fix belongs at a different layer.

There is one more limitation that only shows up after a few weeks. Because the launcher is an ordinary application as far as macOS is concerned, Login Items will happily start it at boot, which sounds useful until three launchers fire at once and Chrome restores three sessions before the network is ready. If launchers are added to Login Items, add them one at a time and watch what the first minute after a restart actually looks like.

When the problem is switching, not launching

Profiles were designed to separate identity, which they do well. They were never designed to organise attention. When ten web apps live behind one icon, the cost is not the click that opens them, it is the constant scanning to work out which window holds the thing being looked for.

The alternative shape is one window per web app, each with its own icon, its own position in the switcher and its own notification identity, so that a badge tells the reader which service is asking for attention rather than which browser. Grouping those windows by the work being done rather than by which account they belong to is the idea behind Workspaces, and the practical question of whether the services in daily use are covered is answered by the list of supported apps.

The trade-offs are real and worth naming. A second browser is another thing to update, sign in to and trust with session cookies. Extensions do not always follow. Memory use goes up when windows stay resident instead of being closed. None of that is a reason to avoid the approach, but it is the reason to decide deliberately rather than installing something and hoping.

What to change first

Read the folder name out of chrome://version, then build one launcher for the profile that gets opened most often. Give it a week, and notice whether the friction has moved from launching to hunting for a window that was already open. If it has, the next thing to look at is a browser that gives each web app its own window and its own Dock icon, which is what SpaceDeck is built to do.