A Chrome shortcut that opens one profile on a Mac

On Windows, adding a Chrome profile offers to put a desktop icon next to it, and double clicking that icon opens that profile and nothing else. On a Mac there is no such offer, no setting that produces one, and no keyboard shortcut in Chrome that jumps straight to a named profile. The avatar button at the top right, then the profile in the list, is the whole interface. Anyone doing that twenty times a day starts looking for the missing feature. It is not hidden. It was never built, and the reason it was never built points directly at what to do instead.

Why Windows has this and macOS does not

A Windows shortcut file is a stored pair: a path to an executable and a string of arguments. Ten shortcut files can point at the same chrome.exe with ten different arguments, and the operating system treats each one as a separate thing to click.

macOS works differently. An application is a bundle in the Applications folder, and Google Chrome is one bundle. One bundle means one Dock icon and one slot in the Command-Tab list, no matter how many profiles or windows exist inside it. There is nowhere for a per profile icon to live, because macOS has no concept of a launcher file that lives outside the bundle and carries its own arguments.

That constraint sets the shape of the work. Creating a Chrome profile shortcut on a Mac means building the small launcher that macOS does not provide. It takes a few minutes, it is entirely supported, and once built it does everything the Windows version does. It also has one limitation that is worth knowing before starting, covered further down.

The profile is a folder name, not the name on screen

This is the step that breaks most attempts, so it comes first.

Each Chrome profile is a folder of user data. On a Mac they live here:

~/Library/Application Support/Google/Chrome/

Inside are folders called Default, Profile 1, Profile 2, and so on. Default is the first profile ever created on that machine. Every profile after it gets a number in creation order.

The trap is that these folder names have nothing to do with the names shown in Chrome. A profile labelled Work, Personal, or Client might sit in Profile 3, Profile 12, or Profile 20. The numbering is not contiguous either. Deleting a profile leaves its number permanently vacant, so on a machine where profiles have been added and removed over the years, the third entry in the profile menu can easily be Profile 17.

The mapping between folder name and display name is stored in the same directory, in a file called Local State, under a key named profile.info_cache. Open it and read the pairs. Guessing the number from the display order is the single most common reason a profile shortcut opens the wrong account, or worse, silently creates a brand new empty profile.

One consequence is worth noting now, because it surfaces months later. The folder number is local to one machine. Moving to a new Mac, or rebuilding Chrome's profiles after a reinstall, hands out different numbers, so a launcher that hard codes Profile 17 will point at nothing recognisable on the new machine. Chrome does not warn about this. It creates the missing profile and opens an empty window that looks like a sign in problem. Anyone who keeps these launchers in a dotfiles repository should treat the profile number as machine specific configuration, not as something to sync.

The one line that opens a single profile

Chrome accepts a startup switch called profile-directory, which selects one profile inside the normal user data directory. On a Mac the invocation is:

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

Two parts of that line are load bearing.

The -n is not optional. The macOS manual page for open describes it as opening a new instance of the application even if one is already running. Leave it out while Chrome is running and macOS simply brings the existing Chrome to the front, discarding everything after it. The symptom is a command that appears to do nothing except raise the window that was already open.

The second is --args. The same manual page states that all remaining arguments are passed to the opened application, and that open itself does not interpret them. Anything placed before --args is read as an instruction to open rather than to Chrome, so argument order decides whether the switch arrives at all.

It is worth separating profile-directory from a switch that looks similar. The Chromium project documents a different approach for developers:

Create a shortcut or alias that launches the browser, using the --user-data-dir command-line argument to specify the profile's location. Source: chromium.org

That switch, user-data-dir, points Chrome at an entirely separate data directory, which produces a parallel browser with its own extensions and its own sign in state. It is the right tool for testing and the wrong tool for opening a profile that already exists in the everyday profile menu. For that, profile-directory is the one. The same Chromium page is also instructive for what it lacks. Its section for Mac instructions still reads "To be provided". The reason clear guidance is hard to find is that the official guidance was never written.

Turning that line into something clickable

A command that has to be typed is not a shortcut. Three ways to give it an icon, in order of how well they hold up.

The Shortcuts app. Create a shortcut, add the Run Shell Script action, paste the line. Shortcuts can be pinned to the Dock and, more usefully, assigned a keyboard combination in their details panel. That produces the thing the search term describes: press a key, land in the work profile. This is the closest match to a per profile keyboard shortcut that macOS offers.

Automator. Choose the Application document type, add Run Shell Script, paste the line, save it into the Applications folder. The result is a real bundle, so it can sit in the Dock and its icon can be replaced through the Get Info panel. Build one per profile and each gets its own entrance.

A .command file. A plain text file containing the line, renamed to end in .command and made executable, runs on double click. It takes thirty seconds to make and opens a Terminal window every time, which rules it out for daily use.

Whichever route is chosen, replace the icon. Three launchers wearing the same default icon in the Dock are three launchers nobody can tell apart, which returns the guesswork the shortcut was supposed to remove. Different colours for work and personal are enough.

What this fixes, and what it leaves alone

The launcher fixes the entrance. Two clicks through a menu become one icon or one keystroke, and the correct profile opens every time.

It does not change anything after that. The launcher is a starting gun, not an application. The window it produces belongs to Google Chrome, so Chrome still occupies exactly one slot in Command-Tab and one icon in the Dock. With eight windows open across three profiles, finding the right one is the same hunt it was before. Nothing about window management improves.

That distinction decides whether this route is enough. For a profile opened once in the morning and left running, it is completely sufficient. For a screen that gets entered and left thirty times a day, solving only the entrance solves the smaller half of the problem, and the next two routes are the ones that matter.

Chrome's own route to a separate icon

Chrome can install a site as an app. In current versions the path is the three dot menu, then Cast, save, and share, then Install page as app. The option moved from where it used to sit, which is why plenty of instructions written a couple of years ago no longer match the menu.

What comes out is a genuinely separate item: its own Dock icon, its own window, its own slot in Command-Tab. The problem of finding the window disappears, because the window has its own identity.

Two constraints come with it. An installed app belongs to the profile it was installed from, so the same site opened under a second account requires switching profiles and installing it again. And the result remains a piece of Chrome, which means Chrome's updates, settings, and window behaviour apply to it.

For a single account per service, it works well. Mail, chat, and an internal admin console are all reasonable candidates.

Making the site itself a separate app

The third route steps outside the browser. A site to app tool builds a standalone macOS application around a single site, with its own bundle, its own icon, and its own stored session.

The important part is what it does to the original question. Most people split profiles to keep sign in states apart: two accounts on the same service, or work history kept out of personal browsing. If each site is already its own application with its own session, there is no profile to switch between. The switching problem is not made faster, it is removed.

What can be set on that app, including its icon, its startup address, and how links leaving the site are handled, is listed on the Features page, and the build steps are walked through in the Guide.

Choosing between the three

Route	Faster entrance	Own Dock icon and Command-Tab slot	Separate sign in per site	Effort
Launcher around the command	Yes	No	No	About 5 minutes
Install page as app in Chrome	Yes	Yes	Tied to one profile	Under a minute
Standalone app from a site to app tool	Yes	Yes	Yes	A few minutes

A profile opened once each morning needs nothing more than the launcher. A screen visited constantly needs its own slot, which means one of the lower two rows. Two accounts on the same service running at the same time points at the bottom row, since that is the only one where sign in state is held per app rather than per profile.

The catalogue of services with ready made settings, on the Supported services page, is a useful sanity check before building anything. The services that show up there are the same ones that tend to cause profile sprawl in the first place, which is a sign that the unit worth separating is often the site rather than the person using it.

What to change first

Pick the single screen opened most often today and give it one entrance, using whichever of the three routes matches how often it is entered and left. Confirm the hand movements actually drop before converting anything else. If that screen turns out to be one of the ones already covered, Kagemusha has a prepared setting for it, and the cost of the standalone route is on the Pricing page.