Making a Chrome shortcut that opens one site only

The instructions you found say to open the three dot menu, choose Create shortcut, and tick Open as window. Two of those three steps still exist. The checkbox does not, and the item that remains does something different from what the article describes. That is why the shortcut on the desktop opens a tab instead of a window. Nothing was done wrong; the menu split in two and most guides were written before it did.

The menu split, and which half does what

Chrome used to expose one command with a checkbox inside it. Ticked, it produced a chrome free window. Unticked, it produced a launcher that opened a tab. That single command was documented everywhere, which is why the old instructions are still the top results.

Chrome's developer blog describes the change:

Starting in Chrome 128, the Create Shortcut menu item in More > Save and share now creates a bookmark on the user's desktop or homescreen. The previous behavior of this menu item on desktop has moved to the Install Page as App option. Source: developer.chrome.com

So the behaviour was not removed, it was moved. Create shortcut is now the bookmark half. Install page as app is the window half. Anyone who wanted the windowed result and got a tab simply needs the item next to the one they clicked.

Both live under the three dot menu at the top right, grouped with casting and sharing. Chrome has renamed that group more than once, so it is more reliable to look for the cluster containing the save and share commands than to follow a written path exactly.

Route one: Create shortcut, when a tab is fine

Open the site, three dot menu, Create shortcut, type a name, confirm. An icon appears on the desktop.

What comes out behaves like a bookmark with a face. Clicking it starts Chrome if it is not running and opens the target page as a normal tab, inside whatever window is already frontmost. The tab strip, the address bar, and every other tab stay exactly where they were.

That is worth stating clearly because it defines who this route is for. If the reason for making a shortcut was that thirty tabs are open and the important one keeps getting lost, this route does not address it. One more tab joins the thirty. The problem is unchanged.

Where it does work is for sites opened a few times a week that do not deserve permanent Dock space. Parked in the Finder sidebar or on the desktop, it removes the step of typing a URL without adding anything that has to be maintained. It also survives Chrome updates without attention, which the third route below does not.

Route two: Install page as app, when a real window is needed

Same three dot menu, the item named Install page as app. On sites that declare themselves installable, an install icon also appears at the right edge of the address bar and does the same job.

What comes out is a standalone window with no tab strip and no address bar, its own Dock icon, and its own presence when switching apps. The properties worth knowing:

• Navigation away from the site becomes difficult by design, since there is no address bar to type into
• The icon can be kept in the Dock permanently
• The session is shared with the Chrome profile that performed the install
• The icon is whatever the site declared, and there is no interface for replacing it
• Everything installed this way is listed at chrome://apps, which is also where it can be removed

The third point is the one that decides whether this route is enough. Sharing the profile means the app is signed in from the first launch, with no setup at all. It also means a second account of the same service cannot be open beside the first, because the app inherits the profile rather than keeping a store of its own. For anyone running a work identity and a personal identity through the same service, that limit arrives on day one.

The bundle Chrome writes lands in the Applications folder inside your home folder, not the system wide one, in a folder Chrome manages for its apps. Finder's Go menu, then Home, gets there. It is worth knowing when an icon has been dragged off the Dock and the question is whether the app itself is still installed.

Route three: launch flags, when the profile has to be pinned

There is one requirement neither menu item covers: guaranteeing that a given site always opens under a specific Chrome profile. Apps made from the menu follow the profile that was active at creation time, which is fine until profiles get reordered or a second one is added.

Chrome accepts a launch flag that opens a URL in app mode, meaning a window with no tab strip, and a second flag that names the profile directory to use. Passing both produces exactly the pinned result. One caveat specific to macOS: when Chrome is already running, the flags are ignored unless the launch is told to open a new instance, so the command has to be written that way rather than simply opening the application.

Typing that line every morning is not a plan, so the usual step is to wrap it. Automator, which ships with macOS, can hold a single Run Shell Script action and be saved as an application. The result sits in the Dock like anything else, and because it is an ordinary app bundle, its icon can be replaced from the Get Info window in Finder by pasting an image.

The gain is full control over both the profile and the artwork. The cost is real: more steps to build, and an obligation to notice when a Chrome or macOS update changes how the flags behave. For one or two critical sites that is a fair trade. For ten it becomes a small maintenance project.

The three routes side by side

	Create shortcut	Install page as app	Launch flags plus Automator
Opens as	A Chrome tab	A standalone window	A standalone window
Time to build	Under a minute	Under a minute	Several minutes
Profile control	None	Follows the profile used	Named explicitly
Session	Shared with Chrome	Shared with that profile	Shared with the named profile
Second account, same service	No	No	Yes, with separate profiles
Custom icon	No	Taken from the site	Yes, via Get Info
Survives updates unattended	Yes	Yes	Needs occasional attention

Reading left to right, control goes up and so does upkeep. A site opened dozens of times a day justifies the right hand column. Most sites do not, and the middle column is where they belong.

The Safari comparison, since it changes the answer

Chrome is not the only route on a Mac, and for one specific requirement it is the wrong one. From macOS Sonoma 14, Safari can save any open page as an app through File then Add to Dock. No install, no flags, no profile to think about.

The difference that matters is the session. Apple's documentation states that a Safari web app shares no browsing history, cookies, website data, or settings with Safari, which is why the first launch shows a signed out page. The same isolation is what lets two apps built from one service hold two different accounts at the same time, with both windows open. Chrome cannot do that from its menu, because its apps inherit the profile that made them.

Safari's route also exposes settings that Chrome's does not. Opening the web app and choosing Settings from its menu bar allows the display name, the icon, and the target URL to be changed after the fact. Changing the URL in place is quietly useful, since a service that restructures its post login path can be corrected without rebuilding anything.

Chrome keeps one clear advantage: extensions. Password managers, clipping tools, and anything a company installs internally keep working inside an app window created by Install page as app. Safari web apps can enable Safari extensions per app, but a Chrome extension does not carry over.

So the rule of thumb is short. Extensions point to Chrome, second accounts point to Safari. A site that needs both at once is the first genuine argument for a dedicated tool rather than a browser feature.

What breaks later

Shortcuts are not build once artefacts, so it helps to know the failure modes in advance.

Deleting a Chrome profile is the most common. Apps installed under that profile keep their icons and lose their sessions, and the repair is to rebuild them. Anyone planning to tidy up profiles should do the tidying first and build the shortcuts afterwards.

URL changes are the second. Services move domains, and post login landing paths get restructured. A pinned URL does not follow. When a shortcut starts landing on a marketing page, rebuilding is faster than editing.

Menu drift is the third. Chrome has moved and renamed these items more than once already, which is the reason this article exists. When handing instructions to someone else, describing the group to look for holds up better than a literal path.

Enterprise sign on is the fourth. Login flows that hop between several domains sometimes fail to finish inside an app window. Build one, let a session expire, confirm that re authentication completes, and only then hand the recipe to the rest of the team. Sessions with long lifetimes make this worse, since a token that expires on day fourteen tends to be discovered after everyone has already switched over.

A plain text note listing which site was built by which route removes most of the pain from all four. Six months later the icon in the Dock gives no clue whether it came from a bookmark, an install, or a script, and rebuilding starts with guessing which menu was used.

Where Chrome's own options stop

Two requirements sit outside what Chrome offers: two accounts of one service open at the same time, and an icon chosen rather than inherited. The launch flag route reaches both with enough assembly. A dedicated tool for turning sites into Mac apps reaches both directly, which is the entire reason that category exists.

When comparing such tools, two things predict the fit better than a feature list. The first is the catalogue of services already handled, since some ship more than 300 presets, and a quick read of a supported services list shows what the tool was designed around. A catalogue of nothing but chat and mail suggests an internal dashboard was never the target. What is adjustable per app shows up on a features page.

The second is the licence shape and the supported macOS range, both cheaper to check before installing than after. Most first hour questions are already answered on a tool's FAQ.

The routes are not mutually exclusive, and setups that last are usually mixed. Bookmark shortcuts for the weekly sites, installed apps for the daily ones, and something purpose built only for the one or two that need a separate identity or a recognisable icon.

What to change first

Take the single site that keeps getting lost among the tabs and give it one app through Install page as app, then leave everything else alone for a week. If the thing that still bothers you after that week is the shared profile or the inherited icon, that is the signal to look at a dedicated builder such as Kagemusha.