Open as window is missing from Chrome: what to do

The routine used to take four seconds. Open the site, go to More tools, choose Create shortcut, tick Open as window, click Create, and a real app icon appeared in the Dock. Today the menu path leads somewhere different, the checkbox is not there, and clicking through produces something that opens in an ordinary tab. Nothing is broken and no setting was toggled by accident. Chrome split one menu item into two in 2024, and the half that makes a windowed app kept the behaviour while giving up the old name. Knowing which item does what settles the immediate problem, and then raises a second one worth answering deliberately.

Where the windowed app option went

The change landed in Chrome 128 and was announced by the Chrome team in July 2024. The item called Create shortcut kept its name and lost its purpose. It now produces a bookmark that launches the page in a new tab, which matches how the same wording has always behaved on Android. The old desktop behaviour moved to a separate item.

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

The current path on a Mac runs through the three dot menu at the top right, then Cast, save, and share, then Install page as app. Chrome's own help page documents the same route and adds that some sites offer an install button at the right hand end of the address bar, which does exactly the same thing in one click.

The checkbox disappeared because it no longer had a decision to make. Install page as app always produces a windowed app, so there is nothing left to tick. That is also why searching for the checkbox inside settings finds nothing: it was not moved to a settings page, it was removed along with the branch of behaviour it controlled.

One detail behind the split is worth knowing, because it removes an old limitation. The install command no longer requires the site to qualify as a progressive web app. Chrome deliberately allows any page to be installed manually, including sites with no manifest and no service worker at all. Pages that once refused to become window apps will now accept it.

Telling the two results apart

Both items produce something that looks like an icon, which is why the split is easy to miss. The difference shows up on the first launch.

	Create shortcut	Install page as app
Opens in	A new tab in the current window	Its own window, no tab strip
Dock and Command Tab	Bounces to the existing browser	Its own icon and its own entry
Lives in	Desktop or the chosen folder	The Chrome Apps folder inside Applications
Listed at chrome://apps	No	Yes
Removed by	Deleting the file	Uninstall from the app menu or chrome://apps

On macOS the storage detail is the fastest way to check what already exists. Installed web apps are filed under a Chrome Apps folder inside the user's own Applications folder, not the system wide one at the root of the disk. Anything sitting there is a real installed app. Anything on the Desktop with a browser icon is a bookmark.

The second reliable check is the address chrome://apps, which lists installed apps only. If a site was set up months ago and its behaviour is now unclear, that page answers the question in one look. Right clicking an entry there also exposes the remove command, which is cleaner than dragging a bundle to the Trash and leaving the registration behind.

The same page is where a shortcut can be added back deliberately. Chrome documents a create shortcut command on the entries at chrome://apps, which places a launcher on the Desktop or in the menu for an app that is already installed. That is the piece the old single dialog used to bundle together: install the app once, then decide separately where the launcher for it should sit. Splitting the two steps looks like extra work the first time and stops mattering after that, because the launcher only needs placing once per app.

What the installed app still shares with the browser

An installed web app is not a separate program. It is the same browser, drawing the same page, in a window with the chrome stripped off. That has consequences that only matter for some sites and matter enormously for others.

The app belongs to the browser profile that created it. It uses that profile's cookies, that profile's saved passwords, and that profile's signed in account. Two accounts on the same service cannot be two installed apps in the same profile, because the second one would open logged in as the first. The standard workaround is a second browser profile, which then creates its own copy of the app, with the profile name attached.

Extensions carry over as well, which cuts both ways. An ad blocker keeps working inside the app window. A screenshot tool or a password manager is still reachable. At the same time, an extension that injects itself into every page is also running inside what looks like a dedicated single purpose app.

Quitting matters too. Closing the app window does not always end the browser process behind it, and quitting the browser can take the app windows with it depending on how the session is arranged. For a site opened once and left running all day, none of this is visible. For someone who restarts the browser several times a day to clear a stuck tab, it is.

Finally, the app follows the browser's release train. It gets security patches automatically, without any action, which is the single largest advantage over a packaged wrapper. Nothing inside it can go stale.

Behaviour worth knowing once the app exists

Three things about installed apps are documented but rarely discovered, and each one removes a reason people abandon the feature after a day.

Uninstalling is done from inside the app itself. The three dot menu in the app window carries an Uninstall entry naming the app, followed by a Remove confirmation. That is the tidy route, because it clears the registration at the same time as the bundle. Dragging the bundle out of the Applications folder leaves the entry behind at chrome://apps, which is why some people end up with a list of apps that no longer launch anything.

Starting at login is a per app setting rather than a system one. Chrome's own help documents a start apps when you sign in option reachable from chrome://apps, which matters for the exact sites this feature suits. A queue or a calendar that is opened first thing every morning is better launched by the system than by a person remembering to launch it.

Right clicking the app in the Dock can show more than the usual window list. Sites are able to publish a short list of shortcuts into that menu, so a mail client might offer compose, and a task tool might offer new task, straight from the Dock icon. Not every site provides them, but checking takes one click, and where they exist they replace two or three navigations inside the app.

One further detail avoids a small surprise later. The name and the icon of an installed app are supplied by the site, and Chrome updates them when the site changes them. An app installed under one product name can therefore change its label in the Dock after a rebrand, without anyone touching it.

When the install option is not there at all

Sometimes the item is missing or greyed out, and it is usually one of four reasons.

The first is version. The wording described above needs Chrome 128 or newer. On an older build the old Create shortcut dialog with the checkbox is still present and still correct. Checking the version at chrome://settings/help settles it immediately.

The second is that the page is already installed. Chrome hides the install command for a site that has an app registered in the current profile, and shows an open or manage entry instead. Looking at chrome://apps confirms it.

The third is the page itself. Internal browser pages, local files, and pages served over plain HTTP behave differently from a normal site on HTTPS, and are the usual candidates when a specific address refuses while every other site works.

The fourth is policy. On a Mac issued by an employer or a school, web app installation can be restricted centrally. The address chrome://policy lists what is being enforced, and anything relevant will be visible there rather than in the ordinary settings.

Deciding which sites earn a window at all

The reason the checkbox is missed is rarely nostalgia for a checkbox. It is that a handful of sites are open every working day and keep getting lost among thirty tabs. That problem is worth solving carefully rather than by installing everything at once.

A site earns its own window when it is opened at fixed times rather than followed from a link, when it needs to be found again quickly through Command Tab, and when leaving it in a tab means losing it. A calendar, a helpdesk queue, a chat client, and an internal dashboard usually qualify. Documentation and reference sites usually do not, because they are entered from a search result and closed again.

The second question is session isolation, and it decides the tool. If one login is enough, the browser's own install command is the shortest route and the safest one, because the engine updates itself. If the same service is used under two accounts, or a client's admin console must stay signed in without touching the personal session, the browser install runs into the profile boundary described above and a separate wrapper app becomes the practical answer.

Anyone weighing that second case can compare what a dedicated app adds before installing anything, since the differences are concrete rather than a matter of taste. The Features page sets out what a standalone app handles that a browser window does not, and the list of Supported services is the fast way to check whether a particular service has already been prepared, which is where most of the manual fiddling with window sizes and sign in behaviour normally goes.

What to change first

Install the one site that gets lost most often, using Cast, save, and share, then Install page as app, and leave it alone for a week before installing a second. If the site needs its own login separate from the browser profile, that route will not hold, and comparing the standalone options at Kagemusha is the next step rather than a second browser profile.