When switching Chrome windows becomes the bottleneck

People searching for Chrome window switching on a Mac arrive with one of two complaints. Either the key combination printed in every guide does nothing at all, or it works fine and still takes four presses to reach the window that was needed. The first problem is a keyboard layout issue and takes about a minute to fix. The second is not a settings problem and cannot be fixed in settings, because it comes from how macOS decides what counts as a separate thing to switch to. Both are worth separating before changing anything, because the fixes point in opposite directions.

Two switchers doing two different jobs

macOS ships two switching mechanisms that get conflated constantly, and reading about one while trying to use the other is why so much advice fails to land.

The first moves between applications. Apple's keyboard shortcut reference describes it plainly:

Command-Tab: Switch to the next most recently used app among your open apps. Source: support.apple.com

The unit here is the app. Ten Chrome windows spread across three profiles still produce exactly one Chrome entry in that list. Landing on it brings forward whichever Chrome window was used most recently, which is frequently not the one that was wanted.

The second moves between windows inside the current app. Same reference:

Command-Grave accent (`): Switch between the windows of the app you're using. (The character on the second key varies by keyboard. It's generally the key above the Tab key and to the left of the number 1.) Source: support.apple.com

The parenthetical is the part that gets dropped in retellings, and it is the part that matters. Apple states outright that the second key changes depending on the keyboard. Most guides copy the shortcut and discard the caveat, which produces confident instructions that silently do nothing on a large share of machines.

Why the key does nothing on some keyboards

macOS stores a default key pair for this action per keyboard layout, and the defaults genuinely differ. On a US layout it is Command plus the grave accent key above Tab. On a Japanese layout the same action is assigned to Command plus the at sign key, because a Japanese keyboard has no grave accent in that position at all.

That single mismatch accounts for most reports of the shortcut being broken. Nothing is broken. The key being pressed is simply not the key that is bound.

The current binding is visible in System Settings, under Keyboard, then Keyboard Shortcuts, then the Keyboard category. The entry is worded as moving focus to the next window. Two things are worth doing while that panel is open. Confirm what is actually bound rather than trusting an article. And if the bound key is awkward to reach, rebind it to something comfortable, since the assignment is editable.

One consequence of that panel is easy to miss. The binding belongs to macOS, not to Chrome. Changing it changes window cycling in every application, and no per app override exists for it. Chrome has no preference of its own that competes with this, which is also why searching inside Chrome's settings for a window switching option turns up nothing.

Cycling is not choosing

Fixing the key gets the mechanism working. It rarely gets the result people were hoping for, because the mechanism was never designed to do what they want.

Command-Tab orders applications by recent use, which makes a single press reliably useful. Window cycling offers no equivalent guarantee. It advances through the windows of the front app in an order that cannot be picked, so reaching the furthest of six open windows takes up to five presses. Worse, each press reshuffles what counts as recent, so the number of presses is never the same twice and cannot be memorised as a habit.

Minimised windows make it stranger. A window sent to the Dock drops out of the cycle entirely. Apple's reference lists Command-M as minimising the front window and Option-Command-M as minimising every window of the app, and either action removes those windows from what cycling can reach. Tidying a window away and then hunting for it in the cycle is a dead end. It has to be clicked in the Dock or surfaced another way.

Then there is naming. A Chrome window takes its title from whichever tab is active. Move between tabs and the window's name changes underneath. Any mental model built on remembering the window by its name falls apart within minutes of ordinary work, and that has a downstream effect: no automation, no menu, and no shortcut can reliably address a Chrome window by name, because the name is not stable.

The practical route out of blind cycling is to display the windows and pick one by eye. Three ways exist. Control-Down arranges the windows of the front app across the screen, which restricts the field to Chrome when Chrome is frontmost. Control-Up arranges every window of every app, which is the right choice when hunting across applications. And the Window menu in the menu bar lists open windows by title near the bottom, which is precise when titles happen to be stable.

Of the three, Control-Down is the one that survives daily use. It also has a clear ceiling. It shows shrunken previews, so four windows all displaying the same admin console look identical at that size, and the search continues after picking one.

Tabs can be addressed, windows cannot

Halfway through this problem, most people start mixing in tab shortcuts, which is worth doing deliberately rather than by accident, because tabs behave in the opposite way.

Chrome binds Command-1 through Command-8 to tab positions counted from the left, Command-9 to the rightmost tab regardless of count, Control-Tab to the next tab and Control-Shift-Tab to the previous one. The first group is positional. Pressing Command-3 goes to the third tab, always, in one press, with no cycling and no ambiguity.

That difference suggests a working rule. Screens belonging to one task should live as tabs in one window, where they become directly addressable by position. Screens belonging to different tasks should not share a window, because mixing them keeps shifting the positions and destroys the one form of addressing that works.

Both directions have a breaking point. Add windows and targeted movement disappears, since windows cannot be addressed. Add tabs past roughly a dozen and the titles compress until tabs are indistinguishable, which reintroduces the same hunting inside a single window. A meaningful share of what looks like a window switching problem dissolves once tasks are grouped correctly, before any shortcut is touched.

What no setting can lift

There is a final constraint that no amount of configuration reaches. Right clicking a Dock icon opens Options with desktop assignment choices, which is genuinely useful for anyone running separate Spaces. The assignment is per application only.

So pinning just the accounting screen to the second desktop while leaving the rest of Chrome on the first is not expressible. The choice applies to Chrome as a whole. Dragging a window across manually works for that moment, with no guarantee about where it lands next time.

These limits share one cause. One Command-Tab slot, one Dock icon, one desktop assignment: all of it follows from macOS treating Chrome as a single application, no matter how many windows live inside it. The number of hops is not high because the wrong shortcut was chosen. It is high because the destinations have no names of their own.

Comparing the routes

Route	Can target a specific window	Reaches minimised windows	Scope
Window cycling (Command plus grave or at sign)	No	No	Windows of the front app
App Exposé (Control-Down)	Yes	Yes	Windows of the front app
Window menu	Yes	Yes	Windows of the front app
Installing the page as an app in Chrome	Yes	Yes	The Command-Tab list
A standalone app built from the site	Yes	Yes	The Command-Tab list

The top three all search inside Chrome, and they share the same ceiling: the more windows there are, the more work each one becomes. Only the bottom two change the shape of the problem, by reducing what has to be searched in the first place.

Giving the destination a name of its own

For screens that are open all day, one option is to move them out of the browser entirely. Two routes do this, and they differ in how far they go.

Chrome's built in route

Chrome can install a site as an app. In current versions the menu path is the three dot menu, then Cast, save, and share, then Install page as app. The option has moved between menus over the years, which is why older instructions no longer match what is on screen.

The output is a genuinely separate item with its own Dock icon, its own window, and its own slot in Command-Tab. For the purposes of this problem, that is the whole fix: the window now has an identity, so it can be reached directly instead of cycled toward.

Two constraints come attached. The installed app belongs to the Chrome profile it was created from, so the same service under a second account means switching profiles and installing it again. And it stays a part of Chrome, inheriting Chrome's updates and window behaviour. For one account per service, neither constraint bites. It takes under a minute and costs nothing, which makes it the sensible first thing to try.

A standalone app built from the site

The other route leaves the browser behind. A tool that turns a website into a standalone Mac app produces an application containing that one site, with its own bundle and its own stored session, and every constraint above inverts at once.

It gets its own entry in the Command-Tab list, so it can be reached directly instead of cycled toward. It gets its own Dock icon, so one click brings it forward. Desktop assignment starts working the way it was wanted, because the accounting screen is now an application and can be pinned to the second desktop on its own. And its name stops depending on which tab is active, which finally makes the window addressable.

What can be configured on such an app is set out on the Features page, and the build steps are walked through in the Guide. The catalogue on the Supported services page is also a useful read before deciding anything, because the services listed there share a trait: mail, chat, spreadsheets, accounting, time tracking. All of them are screens that stay open and get entered repeatedly. Sites that are opened, read, and closed never generate a window switching problem at all.

That points at how to choose. Separate the one screen switched to most often, and leave everything else as tabs. Converting everything moves the congestion into the Dock, where the same hunt starts over with different icons.

What to change first

Open System Settings and confirm which key is actually bound to next window on this keyboard, since that alone resolves the shortcut doing nothing. Then write down the single screen that got switched to most today, and give that one its own entrance. If it is a service already covered, Kagemusha has a prepared setting for it, and the common questions are answered on the FAQ page.