Chrome 155 Split View API Lets Extensions Create Side-by-Side Tabs Without Extra Permissions

With the arrival of Chrome 155, that era of brittle layout hacks is getting a proper, standards-driven replacement. As reported by PiunikaWeb and detailed by Google software engineer Anh Mac on the Chrome for Developers blog, Google has introduced a native Split View API for browser extensions, designed in close collaboration with Mozilla and other browser vendors inside the W3C WebExtensions Community Group.

If you use Windows as a daily productivity workstation—where ultrawide monitors, multi-tab research workflows, and Chromium- or Gecko-based browsers dominate the desktop—this under-the-hood API shift is a big deal. Here is a closer look at how the new API works, why its permission model matters, and where cross-browser support actually stands today.

From Manual Split View to Programmatic Control​

To understand why extension makers have been waiting for this, it helps to look at the timeline. Back in February 2026, Chrome 145 rolled out native Split View to desktop users, allowing people to tile two tabs side by side inside a single browser window without leaning on operating system window snapping or third-party utilities. Mozilla likewise introduced its own native split-view implementation in Firefox during the first half of 2026.

However, there was a catch: in Chrome, only the user could drive the feature through manual browser UI controls. Workspace managers, research assistants, tab-session savers, and translation extensions had no native way to detect whether two tabs were already paired, nor could they spin up a side-by-side comparison on the user's behalf.

Starting in Chrome 155, the Split View API plugs directly into the standard browser.tabs namespace, giving extensions programmatic access to detect, create, and dismantle built-in split views.

The Permission Win: Zero Extra Manifest Prompts​

One of the best practical details in Google's announcement is what developers don't have to put in their manifest.json file. According to the Chrome for Developers documentation, the Split View API lives inside browser.tabs and does not require any additional manifest permissions.

For everyday Windows users and enterprise IT administrators who evaluate browser add-ons, permission creep is a constant headache. Users are rightfully wary when a simple tab-organizing extension suddenly triggers a scary installation prompt asking to read and change all data on visited websites. Because the new split-view hooks operate purely on tab layout state rather than page content, an extension can arrange two tabs side by side without requesting elevated privileges—and without tripping over website security headers that block <iframe> embedding. (Of course, if an extension performs other tasks like reading URLs or injecting scripts, it will still need the standard permissions required for those separate features.)

Section Summary:

• Chrome 145 added user-controlled Split View in February 2026, and Chrome 155 opens that layout engine to extensions via the browser.tabs namespace.
• Using the Split View API itself requires zero extra manifest permissions, avoiding additional installation warning prompts.

Under the Hood: How the Split View API Works​

For software developers building or maintaining WebExtensions, the new capabilities in Chrome 155 revolve around one tab property and three primary operations.

1. Detecting Existing Split Views​

Every Tab object returned by the Tabs API now includes a splitViewId integer property. If two tabs are joined in a side-by-side split view, they share the same unique splitViewId. If a tab is standalone, its splitViewId defaults to -1.

Developers can inspect active splits in the current window with a straightforward query:

const tabs = await browser.tabs.query({ currentWindow: true });
const splitViews = tabs
.map(tab => tab.splitViewId)
.filter(splitViewId => splitViewId!== -1);

2. Creating a Split View​

Chrome 155 provides two distinct ways to construct a side-by-side view programmatically:

• Open a new tab paired with an existing tab: Developers can pass the new splitWithTabId parameter into browser.tabs.create(). By default, Chrome places the newly created tab to the right of the target tab. If the extension needs the new tab to appear on the left side of the split, it simply sets the new tab's index to match the existing tab's index:

// Places the new tab on the right by default
await browser.tabs.create({ splitWithTabId: existingTab.id });

// Places the new tab on the left of the existing tab
await browser.tabs.create({
  splitWithTabId: existingTab.id,
  index: existingTab.index
});

• Pair two already-open tabs: If the user already has both pages open, an extension can join them using browser.tabs.createSplit():

await browser.tabs.createSplit([existingTab1.id, existingTab2.id]);

3. Unsplitting Tabs Cleanly​

When a side-by-side workflow is finished, extensions do not have to close either tab to exit the layout. Calling browser.tabs.unsplit(splitViewId) separates the pair back into two normal, independent tabs while preserving their relative tab-bar order, window assignment, tab group, and pinned status. (Note for developers adapting Google's sample code: because createSplit is asynchronous, make sure you await its returned ID before passing that value into browser.tabs.unsplit.)

Strict Layout Rules Developers Must Respect​

Can an extension randomly grab Tab #1 (pinned in Window A) and pair it with Tab #14 (buried inside a Tab Group in Window B)? Not directly. According to Google's specification, two tabs can only join a split view if they satisfy three strict conditions:

1. Adjacency: The two tabs must already sit right next to each other in the tab strip (or be created adjacent to one another).
2. Exclusivity: Neither tab can already belong to an active split view.
3. Matching State: Both tabs must share the exact same pinned, windowId, and groupId values.

In practice, this means extension authors writing automated workspace tools will need to check tab properties first—and potentially call browser.tabs.move() or adjust tab group assignments—before invoking createSplit().

Section Summary:

• Extensions track split pairs via splitViewId and manage them with splitWithTabId, createSplit(), and unsplit().
• Joined tabs must be adjacent, unsplit, and share identical pinned, windowId, and groupId states.

The Mozilla Collaboration: Shared Standards vs. Current Parity​

While Google and Mozilla worked together through the W3C WebExtensions Community Group to shape how extensions interact with split views—tracked in discussions such as W3C WebExtensions issue #967 opened by engineer Rob Wu in March 2026—developers should be careful not to confuse collaborative API design with simultaneous, identical rollout across every browser.

A look at Mozilla's official Add-ons engineering blog (written by Senior Developer Relations Engineer Christos Bacharakis) shows that Firefox has been rolling out its WebExtensions split-view support in distinct stages:

• Firefox 149: Introduced the read-only splitViewId property on tabs.Tab objects (alongside browser.tabs.SPLIT_VIEW_ID_NONE for onUpdated checks), allowing extensions to detect when tabs enter or leave Firefox's split view.
• Firefox 150: Added the ability for extensions to swap tabs inside a split view, fixed tabs.onMoved event reporting when tab order is reversed, and introduced automatic unsplitting when tabs.move() places previously split tabs in non-adjacent positions.
• Firefox 151: Enabled extensions to move split views within tab groups, while noting that explicit extension-driven creation of split views was still tracked separately under Mozilla Bugzilla ticket 2016928.

Why does this distinction matter? Because cross-browser extension developers targeting both Chrome and Firefox need to use feature detection (such as checking whether typeof browser.tabs.createSplit === "function") rather than assuming that every browser supporting splitViewId also supports createSplit() and unsplit() on the exact same release schedule. Still, having Google and Mozilla align on the browser.tabs data model inside the WebExtensions Community Group means developers won't have to maintain two wildly incompatible paradigms as browser support matures.

(Note: Alongside the Split View API, PiunikaWeb notes that Chrome 155 also introduces a built-in one-click screenshot button inside Chrome's native video playback controls, letting users grab video frames without pausing playback or installing separate screen-capture add-ons.)

Section Summary:

• Google and Mozilla collaborated on the architecture via the W3C WebExtensions Community Group.
• Firefox 149–151 rolled out splitViewId detection, tab swapping, move-based unsplitting, and tab-group movement first, while Chrome 155 ships explicit createSplit and unsplit methods.

Why This Matters for Everyday Browser Workflows​

If you have ever used a research extension that compares a source document against a live translation, a developer tool that pairs API documentation with a staging environment, or a session manager that restores your Monday morning layout with a single click, you have likely felt the jank of old-school multi-window hacks. Resizing two separate browser windows clutters the Windows taskbar and duplicates toolbars, while <iframe> wrappers routinely display blank error boxes on modern websites that forbid framing.

By exposing the browser's native split-screen machinery to extensions—without asking users to surrender extra privacy permissions—Chrome 155 and the broader WebExtensions initiative give developers clean, first-class primitives to build around. Look for tab managers, productivity suites, and AI research companions to start adopting native split-view controls as Chrome 155 reaches desktops.