Chrome 149 Release Date + What Lands for Tab Users (2026)

As of June 2026, Chrome 149 released to stable on June 2, 2026 (build 149.0.7815.x), with late stable June 16; beta opened May 6. For tab users the headline change is BFCache WebSocket disconnect, which makes back-button navigation faster in Notion, Figma, and Slack Web. Vertical tabs and session restore are unchanged.

The feature list is confirmed, not speculative: the official Chrome 149 release notes at developer.chrome.com documented which changes shipped enabled by default, and they carried through to stable.

Chrome 149 Release Date: The Exact Schedule

Chrome 149 reached stable on June 2, 2026, build 149.0.7815.x. Beta opened May 6, 2026; the next milestone, Chrome 150, ships June 30, 2026. If you are reading this in or after June 2026, 149 is already on your machine or one auto-update away.

The rollout is staged: a slice of users get 149 on June 2, the rest by mid-June. That is normal for Chrome’s gradual release. To skip the queue, open chrome://settings/help and let it pull the update.

Key takeaways

• Stable shipped June 2, 2026. Build 149.0.7815.x. Beta opened May 6.
• BFCache WebSocket disconnect: pages with open WebSocket connections (Notion, Figma, Slack Web) now qualify for back/forward caching. Back-button navigation will feel faster.
• CSS Gap Decorations: style the whitespace between grid and flex items natively — no more box-model workarounds.
• Chrome 150 lands June 30, 2026 with the IndexedDB SQLite storage backend that did not make 149.
• Vertical tabs, the Projects Panel, and session restore remain unchanged.

What’s New in Chrome 149 for Tab Users?

Chrome 149 (stable June 2) ships several confirmed default-on changes that touch browsing: BFCache WebSocket disconnect, CSS Gap Decorations, SVG filter sandboxing, the CSS path-length property, and a PWA-scoped system accent color. None alter vertical tabs, tab groups, or session restore. The BFCache fix is the only one a tab-heavy user feels directly.

The Chrome 149 beta blog confirmed these features as enabled by default when the beta channel opened:

The official Chrome 149 release notes are the source for the table above. Anything attributed to 149 but absent from those notes (the IndexedDB SQLite backend is the common mix-up) belongs to a later milestone, not this release.

BFCache WebSocket Disconnect: Better Back-Button in Web Apps

This is the change with the most visible effect on everyday browsing.

The Back/Forward Cache stores a complete page snapshot in memory. Hitting back restores it instantly: sub-100ms, no network round-trip, no re-render. The problem before Chrome 149: pages with active WebSocket connections were ineligible. Chrome could not freeze a live socket, so any app that maintains a persistent WebSocket got slow back-navigation while the page reloaded from scratch.

Chrome 149’s fix closes the WebSocket connection when the page enters bfcache instead of blocking caching entirely. When you navigate back, the page restores from cache. The app’s reconnect logic handles re-establishing the socket.

For tab-heavy users, the practical effect shows up in Notion, Figma, Linear, Slack Web, and other WebSocket-heavy apps. Back-navigation on these feels noticeably faster now that Chrome 149 is on stable.

The reconnect question: apps need to handle the disconnect gracefully. Most already do. A dropped connection and reconnect is a normal network event. Google’s enterprise impact rating on this change is “Low,” which reflects that most apps already have reconnect logic. Poorly written apps that assume a permanent socket could behave unexpectedly, but that’s an edge case.

CSS Gap Decorations: Grid and Flexbox Gaps You Can Style

Grid and Flexbox layouts define gaps (the whitespace between rows and columns) via the gap property. Until Chrome 149, you could not put a visible border or divider line into that gap directly. The workaround was adding borders to individual items and canceling them at edges, which is fragile and verbose.

CSS Gap Decorations adds properties to style those gaps natively. The visual result is similar to what you would get from manual dividers, without the box-model gymnastics. This is enabled by default in stable.

Extension users will not notice any behavior change. Web developers building complex layouts gain a cleaner path to visual structure that previously required workarounds.

Security Changes in Chrome 149

SVG Filters Blocked on Sandboxed Frames

Chrome 149 prevents SVG filter effects from applying to cross-origin iframes and embedded plugins. This closes a rendering isolation gap: a cross-origin iframe could theoretically have its rendering influenced by SVG filters from the parent page. Safari already ships this behavior.

Google’s enterprise impact rating is “High.” Some enterprise web apps use embedded cross-origin content with custom styling that relied on this behavior. Most consumer users will not notice it.

Web App Scope System Accent Color

Chrome 149 restricts the CSS AccentColor keyword to installed PWAs only. Previously any website could read the system accent color, which is a minor fingerprinting vector (it reveals OS-level personalization). Installed PWAs retain access for UI consistency. Normal browsing is unaffected.

What Didn’t Move: Vertical Tabs, Projects Panel, Tab Scrolling

Nothing in Chrome 149 touches the areas Chrome tab users have been watching since Chrome 146:

The gap between Chrome’s native tab features and what extension-based tab management covers has not narrowed in Chrome 149. Named workspaces, session time-travel, keyboard search across open tabs and history, and tab preview without context-switching are not on any announced Chrome milestone.

SuperchargeNavigation covers those via Chrome’s side panel API: named workspaces that persist across restarts, 50 auto-snapshots taken every 5 minutes (a rolling ~4-hour buffer), Alt+K to search open tabs from any page, and Alt+Click to peek at a tab’s content without switching. All free, no account, local by default with optional Chrome-native sync, zero telemetry.

IndexedDB SQLite Backend: Still Targeting Chrome 150, Not 149

Worth repeating because this feature keeps being attributed to Chrome 149 in search results and coverage. Per chromestatus.com, the IndexedDB SQLite backend targets Chrome 150 (stable June 30, 2026), and it does not appear in the Chrome 149 release notes.

What it does when it lands: IndexedDB is the browser’s structured storage API. Notion, Figma, Google Docs offline mode, and many PWAs use it to store data locally. Chrome’s existing backend has had edge-case reliability issues: data corruption after crashes, inconsistent behavior under concurrent writes. The SQLite rewrite addresses this.

Watch for it in 150, not 149.

How to Get Chrome 149 (or Jump to 150 Early)

Chrome 149 installs automatically, so most users already have it. If you are behind:

1. Force the update: open chrome://settings/help. Chrome checks for and installs 149 if you are on an older milestone, then prompts a relaunch.
2. Confirm the version: chrome://version should report milestone 149 (build 149.0.7815.x).
3. Want 150 early? Chrome Dev is already on milestone 150. Download from google.com/chrome/dev/; it runs alongside stable on the same machine.

Watch the 149.x point releases for which Origin Trial features graduate to default-on, plus the security patches that land before Chrome 150 ships June 30.

If you were on Chrome 148 and want to know what changed there, the breakdown is at Chrome 148: What Changed for Tab Users. For the Chrome 147 HTTPS-First changes and the vertical tabs analysis, see the related articles below.