Chrome app mode: a window with no tabs and no address bar

Chrome app mode is the name people use for a Chrome window that has no tab strip and no address bar, holding one site and nothing else. The reason for wanting it is usually specific. A calendar or a chat tool has been living in tab number thirty for months, it keeps getting lost, and a dedicated window with its own icon looks like the fix. Chrome can do this, and it has been able to do it for years, but the feature has two separate entrances that behave differently and a set of limits that are easy to hit on the second day. What follows is what app mode changes, what it leaves untouched, and how to tell whether it is the right lever for the problem.

What app mode actually changes on screen

The visible change is the frame. Google's own description of an installed web app is blunt about it: installed apps lack traditional browser tabs or an address bar. What remains is the page, a title bar, and a small menu. There is no way to type a different URL into that window, which is the entire point. The site cannot drift into something else, and no other tab can appear beside it.

The second change is where the thing lives. An installed app shows up in three places at once. It appears at chrome://apps, which is Chrome's own list of installed apps. It appears in the macOS Dock when running, and it can be given a permanent icon there. From chrome://apps, a right-click on an app gives the option to create a shortcut, and the same menu carries a Launch at startup option that opens the app automatically when the machine comes up.

The third change is subtler and matters more than the frame. Once a site is an app, it stops being something opened by navigating. It becomes something opened by launching, the same way Mail or Messages are launched. That is a change in habit rather than in software, and it is the reason app mode helps some people a great deal and does nothing at all for others. If a site is opened by typing three letters into the address bar out of muscle memory, wrapping it in a window will not stop that habit. If a site is opened by hunting through a row of forty tab favicons, the window will.

Google also notes that installed apps can function without a full internet connection, depending on what the site itself supports. That is a property of the site, not of app mode, but it is worth knowing before assuming the window is only cosmetic.

The two routes in, and why they are not the same

There are two documented ways to get a window with no tabs, and the difference between them decides how much maintenance the setup will need.

The menu route

The supported path runs through Chrome's own menu. Open the site, select More at the top right, then Cast, save, and share, then Install page as app. Some sites show an Install button in the address bar instead, which does the same thing. The result is a real installed app: it is listed at chrome://apps, it gets a Dock icon, and it has its own uninstall path through More and then Uninstall [app name], with an additional checkbox to also delete data from Chrome.

Management for an installed app is thin but real. From inside the app window, More leads to App info and then Settings, which is where permissions for that one site are handled.

The command line route

The older path is a startup switch. Chrome on macOS can be launched directly from its binary with switches appended, and the documented form of that command is this:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

The Chromium project's instructions state plainly that the example switch can be replaced with any other command line switch. The app-mode switch takes a URL as its value. Two details in the same instructions are easy to skip and expensive to skip. The first is the preliminary step: quit any running instance of Chrome before launching with switches, by navigating to chrome://quit. A switch handed to an already-running Chrome is often ignored, which is the usual reason the command appears to do nothing.

The second is the warning the project attaches to switches in general.

Some switches are intended for development and temporary cases. They may break, change, or be removed in the future without notice. Source: chromium.org

That sentence is the real difference between the two routes. The menu route is a product feature and the command line route is a development affordance. Anything built on the second one, a shell script, a saved automation, a login item, is standing on ground that has no stability promise.

Four ways to give a web app its own window

Before committing to app mode, it helps to see it next to the alternatives it is often confused with, because three of them look similar from the outside and separate very different things.

Route	Tab strip and address bar	Stability promise	Where it appears	What it actually separates
Tab in a normal window	Both present	Stable	One tab among many	Nothing
Installed app	Neither present	Documented product feature	chrome://apps, Dock, shortcut	The window frame only
Command line switch	Neither present	May break, change, or be removed without notice	Wherever the script is run from	The window frame only
Separate Chrome profile	Both present	Documented product feature	Profile menu, separate window	Bookmarks, history, passwords, settings

The table makes the trade-off legible. The two app-mode routes remove the browser furniture and change nothing about identity. The profile route keeps the furniture and changes everything about identity. Those are answers to different questions, and picking the wrong one produces a setup that looks right and fails on the thing that was actually bothering the person.

What app mode does not separate

An app window drawn from a profile belongs to that profile. It uses the same cookies, the same saved passwords, and the same signed-in Google Account as every other window in that profile. Nothing in app mode creates a separate session.

This is where the plan usually breaks. Someone who keeps two accounts on the same service installs the site as an app, opens it, and lands in whichever account the profile was already holding. There is no second app to install for the second account, because the app is a window onto a profile and the profile has one session per site.

Chrome's own documentation on cookies draws the boundary in one line: to sign out of a Google Account on all websites, sign out of Chrome. The session is a property of the profile, not of the window. The same page notes that deleting cookies may sign a person out of sites that remember them, which is the other half of the same fact.

Profiles are the mechanism that does separate sessions. Chrome's guidance is to add a profile when more than one signed-in account is in play or when a computer is shared. Each profile keeps its own bookmarks, history, passwords, and other settings, and switching between them runs through the profile icon at the top right. The cost is also documented and worth reading before experimenting: after a profile is removed from Chrome, that profile's bookmarks, history, passwords, and other settings are erased from the computer.

The two features can be combined. A profile per account, with the important site installed as an app inside each profile, gives both separate sessions and separate windows. It also gives a Dock with several icons that look alike and a Chrome that has to be told which profile a launch belongs to, which is the point at which many people decide the arrangement costs more than the tabs did.

What there is no setting for

The documented controls for an installed app are a short list: the app's own settings page reached through App info, shortcut creation from chrome://apps, Launch at startup, and uninstall. Notably absent is any setting that governs where links go.

An app window holds one site, but sites contain links, and a link out of the app window has to open somewhere. Chrome offers no documented control over that behavior, which means the arrangement works well for destinations that are self-contained and less well for hubs that scatter outward. A chat tool where most messages contain a link to somewhere else will keep handing work back to the browser. A calendar or a writing tool that mostly keeps a person inside it will not.

The other absence is grouping. App mode produces one window per app, and it has no concept of a set. Separating work from personal, or client A from client B, means separating the windows by hand every time, because nothing remembers that these five apps belong together and those three do not. That grouping is the gap the Workspaces approach is built around, and it is a different problem from the one app mode solves. Which sites can sensibly be treated as apps at all is worth checking too, since the answer depends on whether the service works as a standalone window, and a list of supported apps is usually faster to consult than testing one by one.

Notifications behave the same way they did in a tab

A common expectation is that moving a site into its own window will also tidy up its notifications, either by making them more reliable or by getting them out of the way. It does neither, because a notification permission is granted to the site inside the profile rather than to the window that happens to be showing it.

The place to adjust that permission from an app window is More, then App info, then Settings, which opens the settings for that one site. Revoking notifications there silences the site everywhere in that profile, including when it is later opened as an ordinary tab. Granting them has the same reach in the other direction. The window frame is not part of the decision.

This matters for the case app mode is most often reached for. Someone who wants a chat tool always running but rarely interrupting is describing a notification problem, and app mode has no answer to it beyond the per-site setting that was already available from the tab. Someone who wants a chat tool to stop being buried is describing a window problem, and app mode answers that directly.

The practical consequence is that the two complaints should be handled separately. Set the notification permission for the site first, from the settings page above, and judge whether the interruptions are at a tolerable level. Only then decide whether the site deserves its own window. Doing it in the other order tends to produce an app window that still interrupts, followed by the conclusion that app mode did not work.

Deciding which problem is actually in the way

Three questions sort this quickly.

If the complaint is that a site keeps getting lost among tabs, app mode is the right tool and the menu route is the right route. Install two or three of the sites that matter most, leave the rest as tabs, and see whether the tab count drops on its own after a week.

If the complaint is that two accounts on the same service keep colliding, app mode will not help, because the session lives in the profile. Profiles are the fix, and the erasure warning above is the thing to read first.

If the complaint is that a dozen web apps have to be arranged and rearranged every day, neither feature addresses it. Chrome has no grouping layer, and building one out of app windows and profiles means maintaining it by hand.

What to change first

Install the single site that gets lost most often, using Cast, save, and share and then Install page as app, and leave everything else alone for a week. If the problem was the tab strip, one app will show it. If the problem turns out to be the number of separate windows now sitting in the Dock, the next thing to look at is a tool that keeps each web app in its own pane and remembers which ones belong together, which is the shape SpaceDeck takes.