Install a website as an app in Chrome and give it its own window
A tab that is opened forty times a day is not really a tab. It is an application that happens to live inside a browser, competing for space with every article, ticket and search result opened around it. Installing that site as an app is the browser's answer to the problem, and it takes about four seconds. What takes longer is working out whether the result is what was wanted, because an installed web app behaves like a native app in some ways and like a tab in others.
What follows is what the installation actually does, where the control sits in Chrome, Edge and Safari as of 27 September 2026, which capabilities appear and which stay behind, and the one limit that stops this technique working for the most common reason people try it.
What installing a website as an app actually changes
Installation is not a download. Nothing is packaged, signed or copied into the Applications folder in the usual sense. The browser reads a file the site publishes, the Web App Manifest, and uses it to create a launcher entry that opens that URL in a window of its own.
The documented result of an install on a desktop operating system is specific. According to the Progressive Web App documentation published on web.dev, an installed app gets an icon in the launcher, appears when the app is searched for on the device, gets a separate window within the operating system, and gains support for certain capabilities that are not available to a page inside a tab.
Once the user installs your PWA, it will: Have an icon in the launcher, home screen, start menu, or launchpad. Appear as a result when a user searches for the app on their device. Have a separate window within the operating system. Have support for specific capabilities. Source: web.dev
On a Mac that means a Launchpad icon, a Spotlight result, a Dock icon while it runs, and a window with no tab strip, no bookmarks bar and no address bar. Cookies, saved passwords and the signed in session come from the browser profile the install was made from, so a site already signed in stays signed in.
The window is the point, not the icon. An installed web app cannot be buried under thirty tabs, because there is no tab strip to bury it in. It shows up in Command-Tab as its own entry. Notifications from it arrive under its own name in System Settings rather than under the browser's name, which matters when the goal is to silence one noisy tool without silencing everything else.
Where the install control sits in Chrome, Edge and Safari
Desktop installation is supported by Chrome and Edge on macOS, Windows, Linux and ChromeOS. Both show an install icon in the address bar when the current site qualifies, and both list an install entry in the browser menu. Chrome may also show a prompt inviting installation once a site has been used enough to look like a tool rather than a visit.
Sites that publish a manifest get the clean version of this. Sites that do not publish one can still be installed manually, so an internal admin panel or a legacy webmail can be turned into a window even though it was never built as an installable app. The icon quality is the usual giveaway: a site with a proper manifest supplies its own artwork, while a manual install falls back to a screenshot or a favicon scaled up.
Safari reached the same place by a different route, and the wording differs. Apple's Safari guide describes it as turning a website into an app: open the site, click the share control in the toolbar, then choose Add to Dock.
An icon for the web app is added to the Dock and Spotlight Applications. If you were signed in to the website, you're automatically signed in to the web app in most cases. Your user name and password remain the same. Source: support.apple.com
Apple also states that the resulting web app has a simplified toolbar and can send notifications like any other app. The practical difference from Chrome is where the session comes from. A Safari web app inherits the Safari login, a Chrome installed app inherits the login of the Chrome profile it was created in, and the two know nothing about each other.
What the installed window keeps, and what it drops
The list of things that stop working surprises people more than the list of things that start.
Extensions are the first. An installed app window runs without the extension toolbar, and while some extensions still act on the page, anything driven by clicking an extension icon has nowhere to be clicked. Password managers used through their toolbar button are the common casualty, which is why the built in browser password store tends to win inside installed windows.
Only two display modes are available on desktop, standalone and minimal-ui, so a site asking for a fullscreen presentation gets a normal window instead. Downloads, printing and file pickers work. Developer tools are still reachable. Back and forward move through history even without visible buttons, and the keyboard shortcuts are unchanged.
Two extras are worth knowing about. An installed app can put a badge number on its Dock icon through the Badging API, which is how a mail or chat app shows an unread count without a visible window. And installed apps can be set to start automatically: in Chromium based browsers, visiting about:apps, right clicking an installed app and choosing the option to start it at sign in removes the morning ritual of opening the same four tools by hand.
The limit that stops this working for two accounts
Here is the sentence that decides most cases. The web.dev installation documentation lists, among the properties of desktop installed apps, that they cannot be installed twice with the same browser.
That single line is why the technique disappoints the people most motivated to try it. Anyone running a work account and a personal account on the same service, or one account per client, wants two windows of the same web app side by side with separate sessions. One install per browser does not provide that. Installing from a second browser profile does, because each profile keeps its own cookies and its own installed apps, but the cost lands elsewhere: the app icons look identical in the Dock, the windows are hard to tell apart, and Launchpad ends up holding several entries with the same name and the same artwork.
The workarounds people reach for in that situation are all forms of separation. Separate browser profiles separate the sessions but not the appearance. A second browser separates both, at the price of running two browsers. A browser designed around the problem separates each account into its own window with its own storage from the start, which is the category described as an app aggregation browser. The Workspaces page sets out how one of those groups accounts and apps into named sets, and the Supported apps list shows which services are handled as first class entries rather than as bare URLs.
Notifications, badges and where the quiet switch lives
The reason to separate a tool into its own window is usually not aesthetics. It is that the tool interrupts, and interrupting tools are hard to govern while they are tabs.
A page inside a tab sends notifications under the browser's identity. Turning them off means turning down the browser, which turns down everything else that was allowed to notify. Once the site runs as an installed app, it becomes its own entry in System Settings under Notifications, in the Application Notifications list, with its own alert style and its own permission to withdraw. Apple's own guidance for website notifications points to the same list, which is where a website that was granted permission can be switched off without touching anything else.
Focus modes then become usable for real work. A Focus that allows notifications from a chat app and blocks the rest can only do that if the chat app exists as a separate app to allow. While it is a tab, the choice is all browser notifications or none.
Badges work the same way. The Badging API lets an installed app put a number on its Dock icon, which is how an unread count becomes visible without the window being open or a notification being fired. That combination, badge on, banners off, is the setting most people actually want for a mailbox: information available on a glance at the Dock, no interruption mid sentence.
The practical test is whether a tool deserves the right to interrupt. Anything that does should be its own window so the permission can be granted narrowly. Anything that does not should stay a tab with notifications refused, which is one decision made once rather than a dialog dismissed every week.
Tab, installed app, or a separate browser window
The three options are not competing for the same job. They differ in what they isolate.
| Tab in the main browser | Installed web app | App kept in its own browser window | |
|---|---|---|---|
| Appears in Command-Tab | No | Yes | Yes |
| Extensions available | Yes | Limited | Depends on the browser |
| Same app twice with two accounts | Yes, in two profiles | One per browser | Yes, by design |
| Notification identity | The browser | The app itself | The app itself |
| Setup effort | None | Seconds | Minutes once |
| Survives a browser restart as a window | No | Yes | Yes |
The pattern that holds up over time is a mix. Tools used all day become windows. Everything read once stays a tab. The mistake is installing twelve web apps because installing is easy, which converts a crowded tab strip into a crowded Dock and moves the problem instead of solving it. Four to six is where most people settle.
Checking what is already installed, and removing it
Installed apps accumulate quietly, especially after a few experiments. In Chromium based browsers, about:apps lists everything installed through that browser, per profile, which is the only reliable inventory. Right clicking an entry there offers removal.
Removal from the Dock is not removal of the app. Dragging the icon out of the Dock takes away the shortcut and leaves the installed app in place, still listed at about:apps and still appearing in Spotlight. Uninstalling properly is done from the browser's list, or from the app window's own menu where one is offered. Storage is a separate matter again: deleting an icon does not necessarily clear the storage the app was using.
For a Safari web app, the entry sits in the Applications folder alongside ordinary apps and is removed the same way, and Apple's guide documents per web app General and Privacy settings, so permissions granted to one are not silently granted to the rest.
What to change first
Install the two sites that are open every working day, nothing else, and leave the rest as tabs for a week. If the thing that goes wrong is two accounts of the same service fighting over one window, the answer is not another install but separate windows with separate storage, which is what SpaceDeck is built to do on macOS.
Frequently asked questions
Does installing a website as an app use less memory than keeping it in a tab?
Not by itself. The page still runs in a renderer process of the same kind, so the memory cost is roughly what the tab cost. The gain is attention rather than resources, because the window stops competing with everything else in the tab strip, and it is easier to notice and quit an app window that is no longer needed.
Will the installed app keep working if the site has no manifest?
Yes, in Chromium based browsers, because a manual install is allowed for any page. What is lost is the polish the manifest would have supplied, such as the correct icon, the app name and the intended window shape. A manually installed app is closer to a shortcut that opens in a window than to a purpose built app.
Can the same web app be installed twice for a work account and a personal account?
Not within a single browser, since a browser allows one install per app. Installing from a second browser profile gives two separate sessions, but both icons look the same and telling the windows apart becomes the new problem. Tools built around per account windows handle this case directly.
Do extensions such as ad blockers and password managers run inside the installed window?
Partly. Extensions that act on page content often continue to work, while anything that depends on clicking a toolbar button loses its entry point because the installed window has no extension toolbar. Checking this with the specific extensions in use, before moving a daily tool into a window, avoids an unpleasant surprise.