Create a Chrome profile shortcut on the desktop, on macOS

The instruction that turns up first says to open the profile menu, find the option for a desktop shortcut, and click it. On a Mac, that option is not in the menu. Nothing is broken and no setting has been disabled. The instruction was written for the Windows build, where Chrome integrates with a desktop that stores shortcut files, and macOS does not work that way.

The goal behind the search is still reachable, and there are three routes to it with genuinely different trade-offs. Picking the right one depends on whether the aim is a double-clickable icon, a Dock item, or something that will still work after Chrome updates itself forty times.

Why the desktop means something different here

On Windows, a shortcut is a small file that points at a program and carries arguments with it. The desktop is a folder full of those files, and Chrome can write one directly, which is why the profile menu offers to do it.

On macOS the desktop is also a folder, sitting at ~/Desktop, but the things that can live in it and be double-clicked are different. An alias points at a file or application and carries no arguments, which is the whole problem, because launching a specific profile is entirely a matter of passing an argument. A .command file is a shell script that Finder will run when double-clicked. An application bundle is a real app that can do anything, including launching Chrome with the right flags.

Only the last two can carry an argument, and that narrows the field immediately. An alias to Chrome on the desktop will open whichever profile Chrome opened last, which is exactly the behavior the reader is trying to escape.

The single fact that everything else depends on is that Chrome accepts a command line switch naming the profile folder, and every workable route on macOS is a wrapper around that switch.

The switch, and the folder name it needs

The switch is --profile-directory, and it takes the name of the folder on disk rather than the name shown in the profile menu. Passed through the macOS open command it looks like this.

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

The -n opens a new instance rather than raising the existing one, and -a names the application. Adding -g opens it without pulling focus, which is useful in scripts that run in the background and unhelpful for a launcher meant to be clicked.

Getting the folder name right is where most attempts fail. Chrome stores profiles in ~/Library/Application Support/Google/Chrome as folders named Default, Profile 1, Profile 2, and so on, and the friendly names are recorded separately in the Local State file. The numbering follows creation order and does not renumber when a profile is deleted, so a browser showing four profiles in its menu can easily have folders numbered up to nine. Guessing based on menu position produces a launcher that opens the wrong account, which is the most common complaint about these setups.

The reliable way to read the mapping is to ask the file directly.

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

That prints one line per profile: the folder name, the display name, and the signed-in address. Copy the folder name from the left column, not the label from the menu.

Three routes, and what each one costs

Route	What sits on the desktop	Cost
A .command file	A plain text file with a terminal icon	Opens a Terminal window every time
A saved script application	A real app bundle, custom icon possible	Two minutes of setup, survives updates
An alias to Chrome	A Chrome icon	Cannot pass a profile, so it does not work

The .command route is the fastest to build and the least pleasant to use. Create a text file containing the open command, save it with a .command extension on the desktop, and make it executable with chmod +x in Terminal. Double-clicking it launches the profile, and also opens a Terminal window that stays on screen. Terminal's settings can be configured to close that window when the command finishes, which removes most of the annoyance but not the flash of a terminal appearing.

The application route produces something that behaves like a normal app. Open Script Editor, which ships with macOS, enter a single line that runs the shell command, and save it as a File Format of Application. Put the result in the Applications folder and place an alias to it on the desktop, rather than putting the app itself there, so that a stray drag does not move the real thing into the trash.

do shell script "open -na 'Google Chrome' --args --profile-directory='Profile 3'"

To give it a recognizable icon, copy any image, select the saved app, open Get Info, click the icon in the top left corner of the info window, and paste. Distinct icons matter more than they sound like they should, because the entire reason for building this is to avoid clicking the wrong account at nine in the morning.

What happens when Chrome is already running

This part surprises people who build the launcher correctly and still get the wrong result. Without the -n flag, open finds the running copy of Chrome and brings it to the front, ignoring the profile argument entirely, because the application is already launched and the arguments only apply at launch. The window that appears is whatever was last in focus, which is usually the wrong account.

With -n, macOS starts a second instance and that instance reads the profile argument. Chrome handles this gracefully, since it is designed to run multiple profile windows from one process, so the result is a new window on the requested profile rather than a duplicate browser. This is also why the launcher works even when Chrome has been open all day.

One behavior is worth testing before relying on it. Running the launcher for a profile that already has a window open does not always produce a second window, because Chromium keeps a single browser process per user data directory and hands the request to the copy that is already running. Whether the result is a new window or the existing one coming forward is easy to check in five seconds, and knowing which happens determines whether the launcher is a launcher or a switcher.

A note on where the icon should live

The desktop is a defensible place for these and often not the best one. On a working Mac the desktop is covered by windows for most of the day, so reaching a desktop icon means hiding everything first. A script application saved in the Applications folder becomes searchable, which means the profile can be launched by typing the first few letters of its name into Spotlight. Naming the app after the account rather than after Chrome makes that work well: an app called "Client Mail" is one keystroke sequence away, while an app called "Chrome Profile 3" requires remembering the number.

The same app can also be dragged to the Dock for a permanent slot, and it can sit on the desktop as an alias at the same time. Building the application once and placing pointers to it in several locations is less work than maintaining separate launchers.

Keeping the launchers working over time

Three things break these setups, and all three are recoverable in under a minute once recognized.

Chrome updates do not break them, which is worth stating because it is the most common worry. The command names the application rather than a version, and the profile folders persist across updates. A launcher built today will still work after a year of automatic updates.

Deleting a profile does break them, as described above, and so does signing out of a profile and signing back in with a different account, which leaves the folder name intact while changing what opens. The second case is worse because nothing looks wrong. The launcher opens a window, the window has tabs, and it takes a moment to notice the account is not the expected one.

Migrating to a new Mac breaks them in a quieter way. Profile folders are recreated in whatever order the new machine sets them up, so Profile 3 on the old machine is very unlikely to be Profile 3 on the new one. The launchers copy across intact and point at the wrong accounts. Rerunning the mapping command on the new machine and updating each script is the fix, and doing it as part of the migration rather than discovering it a week later saves confusion.

What the launcher does not change

A shortcut solves the launching problem and leaves three others in place, which is worth knowing before building four of them.

Chrome remains one application. Every profile window belongs to the same process, they all share one Dock icon, and the app switcher shows Chrome once no matter how many profiles are open. Notifications arrive from Chrome with no indication of which profile produced them. For someone running a personal account and two client accounts, that ambiguity is a daily cost that the launcher does nothing about.

Profiles also separate without protecting. Chrome's help page states that profiles keep bookmarks, history, passwords, and other settings separate, and warns that anyone with access to the device can switch to any other profile on it. A desktop shortcut is a convenience for the person who owns the machine, and it is not a security boundary of any kind.

Finally, the launcher points at a folder name that can change out from under it. Deleting and recreating a profile assigns a new folder, and the old launcher then opens a fresh signed out window instead of the account it used to open. Anyone who has ever seen a shortcut suddenly present a blank new profile has hit exactly this. Rerunning the mapping command and updating the argument fixes it in ten seconds, but only if the cause is understood.

When to stop building launchers

There is a point where the number of wrappers stops being worth maintaining. Roughly, it arrives at the third profile, or at the moment two accounts of the same service need to be visible at once rather than one after another, since a profile window shows one account per service and switching means moving between windows.

At that point the question changes from how to launch a profile to whether the browser should be the unit of separation at all. An app aggregation browser takes the opposite approach, giving each web app its own container with its own session, so that a second Gmail or a second Slack sits beside the first rather than behind it. The Workspaces page describes how those containers are grouped, and the Supported apps page covers which services drop in directly. Anyone comparing that model against subscription products can start from the Compared with Wavebox page.

What to change first

Read the actual folder names out of Local State before writing any script, because a launcher built on a guessed folder name looks like it works and silently opens the wrong account. Build one script application, confirm it opens the profile expected, then duplicate it for the rest. If the count passes three, SpaceDeck is worth looking at instead of a fourth launcher.