Automatic browser tab switching on a Mac

Somewhere between the tenth and the fortieth tab, the act of finding the right one stops being free. The search for automatic tab switching usually starts there. Sometimes the goal is a screen that cycles through dashboards without anyone touching it. Sometimes it is the opposite: a way to land on the correct tab immediately instead of scanning a row of identical favicons. These two goals point at opposite solutions, and picking the wrong one costs a week of fiddling with tools that were never going to help.

Three different jobs hide behind the same phrase

The first job is rotation. A tab is displayed for a while, then the next one, then the next, in a loop. This is what a wall display in an office does, or a second monitor showing build status, error rates, and a support queue in turn. Nobody is watching continuously. The requirement is that the correct thing is on screen when someone glances over.

The second job is targeted jumping. The tab is known: mail, or the ticket that just got assigned, or the chat that just pinged. The requirement is to get there in one motion, without reading tab titles. Rotation is actively harmful here, because a screen that keeps moving on its own is a screen that has to be re-read every time attention returns to it.

The third job is freshness. The tab does not need to be visible, but the data behind it must be current when it does become visible. Plenty of people build a rotation purely to keep pages from going stale, which is solving a data problem with a display mechanism.

Naming the actual job first is what makes the rest of the decision quick. Rotation needs a script or a dedicated tool. Targeted jumping needs keys and structure. Freshness needs to be treated as its own problem, because the browser has specific rules about what a hidden tab is allowed to do, and those rules are the reason the rotation trick disappoints so often.

What the browser will do on its own

Chrome ships no rotation feature. There is no setting that cycles tabs on a timer, and there has never been one. What exists is a set of manual movements that are fast enough to feel automatic once they are in muscle memory.

On macOS, Chrome documents the following in its keyboard shortcut reference. The next open tab is ⌘ + Option + Right arrow, the previous one is ⌘ + Option + Left arrow, a specific tab in the first eight positions is ⌘ + 1 through ⌘ + 8, and the last tab is ⌘ + 9. That last one matters more than it looks, because a tab pinned to the far right is reachable by a single fixed key regardless of how many tabs sit before it.

Pinning changes the arithmetic behind those number keys. A pinned tab shrinks to its favicon and moves to the far left of the strip, and pinned tabs always occupy the leftmost positions. Pinning the four services used every hour makes ⌘ + 1 through ⌘ + 4 stable, because a pinned tab does not move when an ordinary tab beside it is closed. Without pinning, every closed tab shifts the numbering of everything to its right, which is why number keys feel unreliable to people who have never pinned anything.

Tab groups add a second layer. Collapsing a group hides its tabs behind one labelled header, so a window with forty tabs can present as six named blocks. Chrome also carries a tab search list behind the small arrow at the right end of the tab strip, which filters open tabs by page title. Between the two, most targeted jumping is solved without any automation at all.

What is needed	Built into Chrome	Extra tooling required
Move to the next or previous tab	Yes, by keyboard	No
Jump to a numbered tab	Yes, ⌘ + 1 to ⌘ + 8	No
Find a tab by title	Yes, tab search	No
Cycle tabs on a timer	No	Yes
Return focus to a tab when it updates	No	Yes

The gap in that table is narrow and specific. Everything to do with a timer, or with reacting to a change on a page, sits outside the browser and has to come from somewhere else.

Scripting a rotation on macOS without installing anything

Chrome on macOS ships an AppleScript dictionary. Inside it, a browser window exposes a property called active tab index, described in the dictionary as the index of the active tab, and it is writable. That single property is enough to build a rotation, and it needs no extension, no download, and no permission prompt beyond the standard automation consent macOS asks for the first time a script drives another application.

A loop that advances one tab every thirty seconds looks like this:

tell application "Google Chrome"
  set w to window 1
  set n to count of tabs of w
  repeat
    set i to (active tab index of w)
    if i is n then
      set active tab index of w to 1
    else
      set active tab index of w to i + 1
    end if
    delay 30
  end repeat
end tell

Saved from Script Editor as an application, this runs in the background and can be quit from the Dock. The same property can be driven from the Shortcuts app through the Run AppleScript action, which is the easier route for anyone who wants to trigger a rotation from a keyboard shortcut or a Focus mode rather than leave it running all day.

Two practical notes. The script addresses window 1, so it follows whichever Chrome window came forward last unless the window is addressed by its id instead. And a rotation on the frontmost window will fight anyone trying to use the machine, which is why this pattern belongs on a display that nobody types on.

Pinning the rotation to one window

On a Mac driving a second display, the rotation should stay on the dashboard window and leave the working window alone. Chrome's dictionary gives every window an id, so reading the id once and addressing that window by it removes the ambiguity. A short script that lists the id and title of each open window is enough to find the right number, after which the loop refers to window id 12345 instead of window 1. The id survives for the life of the window, so the loop keeps running while other windows are opened, moved, and closed around it.

The delay value also deserves a moment of thought rather than a default. AppleScript's delay blocks the script, so the interval is the display time per tab, and a full cycle takes the interval multiplied by the number of tabs. Eight tabs at thirty seconds is a four minute loop, which is far too slow for anything that changes minute by minute. Reducing the number of tabs in the rotation is almost always better than reducing the interval, because a display that flicks past faster than a person can read is worse than one that shows fewer things.

Why an unattended rotation shows stale pages

A rotation that works perfectly for ten minutes and then starts showing yesterday's numbers is not broken. It is meeting two deliberate browser behaviours.

The first is memory management. Chrome describes what its performance settings do to tabs left alone:

To save your computer's memory and help active tabs run smoothly, Chrome deactivates tabs that you aren't currently using. When you access an inactive tab, it automatically reloads. Source: support.google.com

A discarded tab that reloads on arrival is fine for a static report and useless for anything that needs a login flow, a filter selection, or a chart that takes ten seconds to render. Chrome's performance settings include a list of sites that should stay active, and putting the rotating dashboards on that list is the fix.

The second behaviour is timer throttling, which applies even to tabs that were never discarded. Chrome's documentation on the change introduced in Chrome 88 sets out the condition and the result:

The page has been hidden for more than 5 minutes. The chain count is 5 or greater. The page has been silent for at least 30 seconds. WebRTC is not in use. In this case, the browser will check timers in this group once per minute. Source: developer.chrome.com

A dashboard that refreshes itself with a timer, and sits hidden in a rotation of eight tabs, gets its timer checked once a minute. Pages that use a websocket or server-sent events are unaffected, which is why some tools stay current in a rotation and others do not. Checking which mechanism a given page uses predicts the outcome better than any amount of tuning the rotation interval.

That check takes under a minute. Open DevTools on the page, go to the Network panel, and filter by WS. A page holding a websocket shows one long-lived connection there and will keep receiving updates while hidden. A page with nothing in that filter, but a request to the same endpoint repeating at a fixed interval, is polling with a timer and will slow to one check per minute once it has been hidden for five. Pages in the second category belong at the front of the rotation or on a permanently visible window, not buried in a cycle of eight.

Judging an extension before it becomes the plan

Rotation extensions have existed for years, and the search results still point at several. There is now a hard filter to apply first. Chrome finished removing the old extension platform, and the timeline page states the end point plainly:

All remaining Manifest V2 extensions are removed from the Chrome Web Store. Manifest V2 extensions installed on Chrome 138 or earlier will remain installed, but will be unable to receive any updates and cannot be reinstalled from the Chrome Web Store once removed from Chrome. Source: developer.chrome.com

The practical consequence for a reader in 2026 is that a blog post recommending a tab rotator, written before 2025, is describing something that may no longer be installable. Two checks separate the survivors. Look at the last update date on the store listing, and look at the permissions the listing declares. A rotation only needs the ability to read and change tabs. A listing that also asks to read data on all sites is asking for far more than the job requires, and tab utilities have a documented history of changing hands and gaining behaviour their original users never agreed to.

The same reasoning applies to the alternative of writing the rotation as a small unlisted extension. That is a real option, and the tab API it needs is short, though the effort is only worth it when a script driven from outside the browser cannot reach the pages involved.

When the honest answer is fewer tabs

Rotation is a display technique for screens nobody touches. For a working machine, the number that predicts wasted time is not how fast tabs can be switched but how many things are competing inside one window.

The count matters because tabs share a strip of fixed width. Past roughly a dozen, titles disappear and only favicons remain, at which point two Google properties look identical and the only way to identify a tab is to click it. Every keyboard shortcut in the earlier table degrades in the same way: ⌘ + 1 through ⌘ + 8 covers the first eight positions, and positions shuffle whenever a tab is closed.

Splitting by purpose rather than by page fixes the identification problem at its root. One window per job, each holding the three or four services that job needs, means switching happens at the window level with ⌘ + ` or through Mission Control, and each window keeps a stable, readable set of tabs. A browser built around that shape gives each web app a persistent place instead of a position in a queue, which is what Workspaces describes, and the services that are set up to run that way are listed under Supported apps.

What to change first

Decide which of the three jobs is actually in play. If it is rotation on an unattended screen, write the AppleScript loop, add the rotating sites to Chrome's list of pages that stay active, and check whether each page refreshes by timer or by socket before blaming the script.

If the goal was never rotation but the daily cost of hunting for the right tab, stop automating the switch and reduce what has to be switched between. Giving each web app its own window is the version of that fix that survives a busy day, and SpaceDeck is built around it.