If you’ve ever tried to manage 30–40 open tabs in a browser with a widescreen monitor, you likely understand the appeal of turning the tab bar on its side. That’s been the standard in browsers like Microsoft Edge, Vivaldi and others for years. Meanwhile, Chromium-based browsers (including Google Chrome) kept using a horizontal tab strip. Until now.

Recent commit activity in Chromium’s review system indicates that the development team is laying serious groundwork for vertical tabs: feature flags, preference keys, layout branching — all the foundational plumbing that must be in place before a feature can be enabled for users. Some of this is hidden behind internal issues and early CLs, but public indicators point clearly in this direction. For example, issue #420041296 on the Chromium issue tracker is titled Add Sharing Option and Vertical Tab List Display. 

Why it’s taken so long

The reason vertical tabs did not land earlier boils down to architecture. Chromium’s UI stack was built around the assumption of a horizontal tab strip at the top of the browser window. Layout code, event handling (drag/drop of tabs, overflow behaviour), extension APIs, theming — all of these assume a single row of tabs across the width of a window.

To flip that — to allow tabs to live in a sidebar, stack vertically, scroll differently, resize differently — means refactoring many components. It also means maintaining compatibility with legacy behaviours (extensions, windowing, profiles) and introducing a toggleable path (so horizontal mode still works). So rather than delivering a piece-meal version, the team appears to be building the infrastructure first: flag, orientation abstraction, metrics.

What the code is showing

Several observable changes hint at the direction. First: a preference key. In the Chromium source there’s a constant in chrome/common/pref_names.h that reserves a boolean vertical_tabs.enabled-like preference. That alone signals the user-state for vertical tabs is anticipated.

Second: the flag registration. In chrome/browser/about_flags.cc you see how flags are enumerated for exposure via chrome://flags. While the exact vertical tabs entry is not immediately visible in the public snapshot I found, the pattern is unmistakable. 

Third: layout code shows how the tab strip currently uses horizontal assumptions. For example, in chrome/browser/ui/views/tabs/tab_strip.cc, there’s this snippet:

void TabStrip::UpdateNewTabButtonBorder() {
  const int extra_vertical_space = GetLayoutConstant(TAB_HEIGHT) -
                                   GetLayoutConstant(TABSTRIP_TOOLBAR_OVERLAP) -
                                   NewTabButton::kButtonSize.height();
  constexpr int kHorizontalInset = 8;
  new_tab_button_->SetBorder(
      views::CreateEmptyBorder(gfx::Insets(
          extra_vertical_space / 2, kHorizontalInset, 0, kHorizontalInset)));
}

Here, the code is explicitly computing vertical spacing under the assumption the tab strip is horizontal — illustrating how much of the UI logic will need adjustment for a vertical layout. 

Putting these together, one of the key internal changes likely looks something like this:

// In tab_strip_model.h or equivalent:
enum class TabStripOrientation {
  kHorizontal,
  kVertical,
};

// In the constructor:
TabStripModel::TabStripModel(Profile* profile, Browser* browser)
   : orientation_(TabStripOrientation::kHorizontal),
     browser_(browser) {
  if (base::FeatureList::IsEnabled(features::kVerticalTabs) ||
      profile->GetPrefs()->GetBoolean(prefs::kVerticalTabsEnabled)) {
    orientation_ = TabStripOrientation::kVertical;
  }
}

And elsewhere in the UI layout:

if (orientation_ == TabStripOrientation::kVertical) {
  // use SidePanelTabStripView for vertical layout
  view_ = std::make_unique(...);
} else {
  // existing HorizontalTabStripView
  view_ = std::make_unique(...);
}

While I cannot point to a public commit hash in this post (those CL IDs are internal/private), the issue tracker (#420041296) and media coverage give enough of a confirmation that such changes are underway. 

What this enables — and what still needs work

With orientation abstraction and feature flags in place, Chromium can begin to support two workflows: keep the classic horizontal tab bar for most users, and allow power users to switch to a vertical sidebar layout. That sidebar would offer stacked tabs (with full titles visible), easier tab-grouping, improved scanning of many open tabs — especially on ultrawide monitors.

But the path ahead still has work. The UI needs to support resizing the sidebar, collapse/expand behaviours, theming in sync with the horizontal UI, drag-and-drop within vertical stacks, overflow handling (scrolling vertically instead of horizontally), and extension API compatibility (many extensions assume tabs in the top row). Telemetry must collect data on usage and performance to ensure the feature can roll out widely without introducing regressions.

It’s also unclear exactly when the user-facing toggle will appear in stable builds. At this stage, the flag is likely only in early builds (e.g., Chromium Canary) or internal builds, and a public release date hasn’t been announced.

Why it matters

For developers, browser-power users, and people who keep dozens of tabs open, this is a welcome shift. A vertical tab layout reduces cognitive load: you can read full titles, group tabs visually, and use side space that would otherwise go unused on wide screens. From an engineering perspective, it’s interesting because it reflects a fundamental UI-architecture change: a once horizontal-only model is now turning into an orientation-agnostic layout. That’s non-trivial in a codebase as large and cross-platform as Chromium.

The presence of the feature flag and orientation logic shows the Chromium team is taking their time — building the groundwork, gathering telemetry, preparing for extension compatibility — rather than shipping a quick hack. That suggests this isn’t just an experiment: it’s likely coming to users in a meaningful way.

In summary: vertical tabs are coming to Chromium. The architectural foundation is actively being laid. For anyone who tills the browser tab jungle every day, this is a change worth preparing for.