Turning a website into an app with Chrome on a Mac

The operation itself takes under a minute. Open the site, three dot menu, Cast save and share, Install page as app, done. What takes longer is finding out what that app actually is, because it looks like a separate program in the Dock and behaves like a browser window in every way that matters to a login. Anyone installing more than one site as an app runs into that gap within a week, usually while trying to keep two accounts of the same service open at once.

The current route, and the item that shares its old name

On a Mac, the path runs through the three dot menu at the top right, then Cast, save, and share, then Install page as app. Some sites also show an install icon at the right hand end of the address bar, which does the same thing in one click.

The confusing part is that a second item, Create shortcut, still sits nearby. The two were split apart in 2024 and now do different jobs. Create shortcut produces something closer to a bookmark, which opens in a normal tab. Install page as app produces a window with no tab strip and no address bar, with its own icon and its own entry in Command Tab. If the result opened in a tab, the wrong item was used.

One limit that used to exist is gone. The install command no longer requires the site to qualify as a progressive web app. A page with no manifest and no service worker can be installed manually, which is what makes this route usable for internal admin panels and older tools that were never built with installation in mind.

After installation, the app bundle is filed in a folder named Chrome Apps inside the Applications folder in the user's home directory, not the shared one at the root of the disk. That location is the fastest way to confirm that a real app was created rather than a shortcut. The list of everything installed lives at chrome://apps, which is also where the management commands are.

What the app keeps sharing with the browser

An installed web app is not a separate program. It is the same browser drawing the same page with the window furniture removed. Three consequences follow from that, and all three surprise people at some point.

The session belongs to the browser profile that installed it. The app uses that profile's cookies, its saved passwords, and its signed in account. Signing out inside the app signs the browser tab out too, because there is only one session underneath.

Extensions reach inside as well. An ad blocker keeps working in the app window, and so does a password manager, which is convenient. It also means an extension that injects itself into every page is running inside what looks like a dedicated single purpose application.

The process is continuous with the browser. Closing the app window does not always end the browser process behind it, and quitting Chrome can take the app windows with it, depending on how the session was arranged. For a site left open all day this never surfaces. For someone who restarts the browser several times a day, it surfaces constantly.

There is a real advantage on the other side of that coupling. The engine rides the browser's update train, so security patches arrive automatically with no action and nothing inside the app can go stale. That is the clearest edge this route has over any packaged wrapper, and it is worth weighing before reaching for something heavier.

Where the route stops: a second account

The hard boundary shows up when the same service is needed under two identities. A work calendar and a personal calendar. A client's admin console and an internal one. Installing the site twice in the same profile does not help, because both copies read the same cookie store and the second one opens as the first account.

The documented workaround is a second browser profile. Create one, install the site again from inside it, and a separate app bundle appears with the profile name attached. It works. It also multiplies everything else: extensions, bookmarks, settings, and default link handling all become per profile, and keeping two of them aligned is ongoing work rather than a one time setup.

	Install in Chrome	Second Chrome profile	Standalone wrapper
Setup time	Under a minute	Profile first, then install	A separate install
Cookie store	Shared with the profile	Separate per profile	Isolated per app
Two accounts, one service	No	Yes	Yes
Extensions	Carry over	Managed per profile	Depends on the tool
Custom icon	No, taken from the site	No	Usually yes
Updates	Follows Chrome	Follows Chrome	Follows the tool

The table has one decision in it. If a single login is enough, the browser route is shorter and safer. If two sessions have to stay alive side by side, the choice is between managing a second profile or using a tool that isolates sessions per app.

Three settings that change how the app feels

Most of what is worth knowing after installation is in one place, and it is not the settings page.

Launch at startup is set per app. Right click an entry at chrome://apps and the option is there. For the sites this feature actually suits, a queue or a rota or a dashboard opened first thing every morning, having the system open it is more reliable than remembering to.

Shortcut placement is a separate step from installation. The same right click menu carries a create shortcut command that puts a launcher on the Desktop or in another chosen location. Registering the app and deciding where its launcher sits used to be one dialog, and splitting them looks like extra work exactly once.

Uninstalling is cleanest from inside the app window. Its three dot menu carries an uninstall entry naming the app, with an option to also delete the data Chrome holds for it. Dragging the bundle to the Trash removes the file and can leave the registration behind at chrome://apps, which is how people end up with a list of apps that launch nothing.

One thing cannot be changed on this route. The name and the icon come from the site, and Chrome updates them when the site does. An app installed under one product name can quietly relabel itself in the Dock after a rebrand. Where several similar looking services are installed side by side, that matters more than it sounds.

When the site changes underneath the app

Because the app is the site, changes on the server arrive without warning. Three of them account for most of the confusion.

The first is a changed address. If a service moves to a new domain, or shifts the post login landing page to a different path, the app keeps opening the old one. A redirect covers it for a while, and the day the redirect is retired the app opens an error page instead. There is no field to edit the start URL after installation on this route, so the fix is to uninstall and install again, which takes about as long as it took the first time.

The second is a changed identity. A rebrand replaces both the name and the icon, since both come from the site. Two services with similar icons can become genuinely hard to tell apart in the Dock from one day to the next, and there is no way to override either one here.

The third is a changed sign in flow. When a service moves to an external identity provider, the authorisation step sometimes opens outside the app window instead of inside it. The login still completes, but the flow splits across two windows, which is mildly annoying once and consistently annoying every morning. That behaviour depends on how the site implements the redirect and cannot be configured locally.

None of these are faults in the installation. They are the site moving while the container stays still. Reinstalling is cheap enough that treating it as routine maintenance, rather than as troubleshooting, is the right posture.

Deciding which sites are worth installing

Installing every open tab moves the problem from the tab strip to the Dock without shrinking it. Two questions settle most cases.

The first is how the site gets opened. Sites entered deliberately at fixed times belong in a window: a calendar, a chat client, a support queue, an internal dashboard. Sites entered from a link or a search result and closed again do not. Documentation and reference material stay fine as tabs.

The second is what it costs to lose it. If closing a tab group by accident means hunting the site down again and signing back in, a window earns its place. If reopening takes two seconds, it does not.

When it is genuinely unclear, install the single site that is open longest, then leave it for a week. If the Dock icon gets used, the change worked. If the old habit of hunting through tabs continues, that site was fine where it was, and nothing was lost by testing it.

Order matters when the list grows. Adding one site at a time makes it obvious which ones changed a habit and which ones were installed because installing was easy. Installing ten at once produces a Dock full of icons with no way to tell the useful ones from the rest, and the clean up is then guesswork. Most people settle at three to five, and that is the number worth aiming at rather than a full conversion of the tab strip.

There is one more filter worth applying before installing anything: whether the site tolerates a window with no address bar. Tools that hand out deep links, or that expect a page to be opened in a new tab from an email, can behave oddly when the destination is an app window rather than a browser one. Testing that with the single first install answers it for the whole category, since the sites that suit this treatment tend to behave the same way.

Comparing the standalone route before committing

If the second account problem is the reason for reading this, the browser route will not solve it and a second profile is only one of the available answers. Before comparing tools, three things are worth checking, because they decide the outcome more than any feature list does.

Which services a tool has already been prepared for is the fastest signal of what it was built for, and the list of Supported services answers that in one look. What a standalone app can do that a browser window cannot, meaning isolated sessions, custom icons, remembered window sizes and per app notification control, is set out on the Features page. How much hands on work is involved is visible in the Guide, which is the part most feature lists leave out.

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 that site needs a login separate from the browser profile, the route runs out there, and the standalone options at Kagemusha are the next thing to compare rather than a second browser profile.