Google Chrome shortcuts on a Mac: two meanings, one search

Searching for a Chrome shortcut returns two unrelated kinds of page, and neither set is wrong. The word covers a key combination pressed inside the browser and a clickable icon that opens a website, and Google documents them separately in its own help center. Add the word PC to the search and a third source of noise arrives, because most step lists written under that word were written for Windows and use a modifier key that a Mac does not have in that position. Splitting the term into its parts turns a messy search into three short answers.

Google documents this on three different pages

The help center itself shows the split. One page is titled Create shortcuts for websites in Chrome. A second page, Use web apps, describes installing a site so that it behaves like an application. A third page lists keyboard shortcuts, and that one is divided by platform before it lists anything.

Those three pages answer three different questions. The first produces something to click. The second produces something that appears to the operating system as a program. The third changes nothing at all and only tells the reader which keys the browser already listens for.

Most confusion in this search comes from landing on the wrong one of the three. A reader who wanted an icon in the Dock reads a table of key combinations and concludes the feature does not exist. A reader who wanted faster tab switching finds instructions about creating a file and assumes the browser has changed. Both are reading accurate documentation for a question they did not ask.

The practical filter is simple. If the goal is to move around inside a browser that is already in front of you, the answer is a key combination. If the goal is to reach a specific site from anywhere, including when the browser is closed, the answer is an icon, and the icon comes in two versions.

Two menu items sit next to each other and produce different things

Both icon-producing options live in the same submenu, which is the main reason they get mixed up. Google's instructions for the first one read: at the top right, select More, then Cast, save, and share, then Create shortcut. A dialog appears offering the default name or a rename, and then Create.

The instructions for the second one are almost identical: More, then Cast, save, and share, then Install page as app. On some sites an Install control also appears at the right of the address bar.

The results are not the same. The installed version is what Google calls a web app, and its documentation describes web apps as able to carry extra features such as more storage for offline browsing, notifications, file system access and icon badges. It also gets an entry that can be managed from the browser, and Google notes that web apps can be reviewed and removed at the chrome://apps address, or uninstalled from the app's own window through More and then Uninstall.

There is one behaviour of installed apps worth knowing in advance, because it looks alarming the first time. Google documents that when a web app wants to change its own name or icon, the browser shows an App update available control in the top right of the app window, and the update can be accepted, ignored or the app uninstalled. The help page adds the reason: a name or icon that suddenly resembles a different app is treated as a signal to uninstall rather than accept.

A second practical difference shows up later rather than at creation. The plain shortcut is a single object whose only property is where it points. Nothing tracks it, nothing lists it, and if it stops working the only diagnosis available is opening it and watching what happens. The installed version is registered with the browser, which means there is a place to look when something is wrong and a defined way to remove it cleanly along with its stored data.

For a site opened a handful of times a week, that difference is academic and the lighter option is the better one. For a site opened forty times a day, the ability to inspect, rename and remove it without guessing is the entire reason to prefer the heavier option.

Where key lists written for Windows stop working

Google's keyboard shortcut page splits by platform before listing a single combination, and comparing the two halves shows why copied lists fail. On Windows a new window is Ctrl and n. On a Mac the same action is ⌘ and n. Closing a tab is Ctrl and w against ⌘ and w. Full screen is F11 on Windows and Fn with f on a Mac.

Two entries have no straightforward Windows equivalent at all. Jumping to the next open tab on a Mac is ⌘ with Option and the right arrow, and the previous tab is the same with the left arrow. Jumping straight to a numbered tab is ⌘ and 1 through ⌘ and 8, with ⌘ and 9 reserved for the last tab rather than the ninth. That last detail catches people who assume the numbering simply continues.

The Mac section also opens with a note that has nothing to do with the browser. Keyboard navigation is turned on by default in system settings, and some navigation options require Full Keyboard Access to be allowed on the device. A reader whose keys do nothing is sometimes looking at an operating system setting rather than a browser problem.

None of this makes Windows guides wrong. It makes them unusable without translation, and translation is exactly what a hurried reader skips.

The same platform gap runs through the icon side of the question, in a way that is easier to miss because the menu path is identical. On Windows, a created shortcut lands as a file on the desktop, and the desktop is a normal place to keep such files. On a Mac the equivalent place is the Dock and the Applications folder, and a file left loose on the desktop is not how anything else on the machine is launched. Following a Windows article to the letter therefore produces a working result that sits in the wrong place and gets tidied away within a week.

There is also a difference in where the operating system lists what was created. Windows guidance points at a taskbar and its own settings for notifications. On a Mac, the equivalents are the Dock and the notification list in system settings, and what appears in that list depends on which of the two menu items was used. That is a second reason the two nearly identical menu entries deserve to be read carefully rather than picked at random.

The shortcut that does not exist: one key that opens one site

The request underneath most of these searches is narrower than either answer. It is a single key combination that jumps straight to one specific site, from anywhere, without hunting.

The browser does not offer that. Its published list is a fixed set of in-browser actions, and every entry assumes the browser is already frontmost. A key that works while a different application is in front is an operating system feature, not a browser one.

macOS does provide a version of it, with a condition attached. Apple documents that custom keyboard shortcuts can be created for menu commands in any app, under System Settings, then Keyboard, then Keyboard Shortcuts, then App Shortcuts, either for one chosen application or for all applications. The condition appears in the same page: some apps may not allow shortcuts to be set.

The structural problem is what that mechanism binds to. It binds to a menu command inside an application. A website open in a tab has no menu command of its own. There is nothing for the shortcut to point at, which is why this approach cannot reach a tab no matter how it is configured.

It is worth being precise about what this rules out, because a lot of advice on this topic quietly assumes otherwise. Assigning a key to a bookmark does not work, because a bookmark is a list entry rather than a menu command. Assigning a key to a tab does not work for the same reason. Assigning a key to the browser itself works, and it brings the browser forward, which leaves the reader exactly where the problem started: in front of a window holding twenty tabs, one of which is the destination.

An installed site changes that, and not because of any clever feature. It changes because the site becomes an application, and applications are what the switcher and the shortcut system already know how to address. Command and Tab reaches it. A launcher finds it by name. The site stopped being content inside a program and became a program.

What each answer actually solves

	Keyboard shortcut	Created shortcut	Installed web app
Where it is documented	Keyboard shortcuts page	Create shortcuts page	Use web apps page
Works when the browser is closed	No	Yes	Yes
Own entry in the application switcher	No	No	Yes
Can hold notifications and offline storage	Not applicable	No	Yes, per Google's description
Manageable in one list	Not applicable	No	Yes, at chrome://apps
Reachable by a custom key combination	Already is one	No	Through the operating system

Reading down the last column shows why the installed route absorbs the other two for a site opened all day. Reading down the first column shows why it does not replace them for anything else: no icon will ever move between tabs faster than a key.

Deciding by frequency rather than by feature

The useful sorting rule is how often a site is opened, not what the site is. Sites opened once or twice a day are fine as bookmarks. Sites opened constantly are the ones where the three steps of finding the browser, the window and the tab add up to real time.

That second group is smaller and more predictable than people expect. The supported services list is a reasonable proxy for it: mail, chat, boards, dashboards and the assistant sites. What they have in common is not category but rhythm. Internal tools belong on the same list and are usually missed, because nobody thinks of a payroll console as an app candidate even though it is opened as often as chat. The features page is the place to check what a shell carries beyond the icon, since naming, icons and account separation are the parts the browser's own two menu items leave alone.

What to change first

Decide which of the three answers the actual problem needs, then use the smallest one that solves it. For a site opened all day, install it rather than creating a plain shortcut, because only that version becomes an application the rest of the system can address, and the Kagemusha guide covers doing the same for the rest of the list at once.