Chrome ships every 14 days from 8 September 2026: the release-cadence playbook for web and QA teams

Summary. Chrome moves from a four-week to a two-week release cycle with the stable release of Chrome 153 on 8 September 2026, a change announced on 3 March 2026 and covering Desktop, Android and iOS. Extended Stable keeps its eight-week cycle, but it runs on managed Windows and Mac only, so mobile Chrome moves at the new pace whatever your enterprise policy says. The reason is stated plainly in Google's 30 July 2026 security post: in Chrome 149 and 150 the team fixed 1,072 security bugs, more than the previous 23 milestones combined, and it is now piloting two security releases per week on top of the two-week milestones. Google also joined a $12.5M donation to the Alpha-Omega project, and Chrome now tracks more than 2,300 third-party dependencies. The consequence for your backlog is arithmetic: every deprecation you have filed as "Chrome 158" or "Chrome 176" now arrives in half the wall-clock time it would have under the old cadence. XSLT removal at Chrome 158 lands on 17 November 2026, exactly 12 weeks after Chrome 152 on 25 August 2026.

This is what to change in testing, CI and enterprise rollout, in the five weeks left before the first two-week milestone.

What actually changes on 8 September

A new beta and a new stable version of Chrome ship every two weeks, starting with the stable release of Chrome 153 on 8 September 2026. The change applies to Desktop, Android and iOS. Dev and Canary channels are unchanged. A Chrome Beta for each version ships roughly three weeks before that version's stable release.

The published schedule for the transition milestones shows how compressed the branch-to-stable path becomes:

Read the M154 column carefully. Under the old schedule M154 branched on 21 September; under the new one it branches on 31 August, three weeks earlier. If your compatibility testing keys off the branch date, that window has already moved and the first affected milestone branches this month.

Chrome has shipped a milestone every four weeks since 2021. In 2023 the team added a weekly security update to improve the patch gap and introduced the Early Stable release to improve release quality. The two-week cadence is the next step in that sequence rather than a departure from it. The announcement's own framing, from Ben Mason and Deepak Ravichandran of the Chrome team, is that "while releases will be more frequent, their smaller scope minimizes disruption and simplifies post-release debugging."

Why Chrome is doing this: the bug curve moved first

The cadence change follows a change in how many security bugs Chrome finds. Google's Chrome Security Team documented the mechanism on 30 July 2026.

In early 2026 the team built an agent harness using Gemini to find vulnerabilities across the Chrome codebase. One result was a sandbox escape that let a compromised renderer trick the browser into reading local files, a bug that had survived in the codebase for more than 13 years. By March 2026 the Chrome Vulnerability Reward Program had received more bug reports than in the whole of 2025, which forced a change to the programme's rules.

The fix rate followed. Triage of a single security report historically took 5 to 30 minutes or more of human expertise; an automated pipeline now handles filtering, reproduction, metadata enrichment and routing, saving what Google estimates at hundreds of developer hours per month. BigSleep and CodeMender run inside continuous integration every 24 hours across all changelists, and in May 2026 alone that blocked more than 20 vulnerabilities from reaching production, including one critical issue.

Which brings the number that explains the release calendar: across Chrome 149 and 150, the team fixed 1,072 security bugs, more than the total fixed across the previous 23 milestones combined.

Fixing bugs faster creates a second problem, and Google names it. Once a fix lands in the public open-source tree, attackers can reverse-engineer it before the fix reaches users. That window is the patch gap, and N-day exploitation lives in it. The Chrome Security Team's conclusion is blunt: "In the face of fast-moving, AI-powered attacks, our delivery cadence must accelerate even further. To meet this moment, we are piloting a shift to two security releases per week."

So the real 2026 cadence for a security-sensitive fleet is not fourteen days. It is a major milestone every fourteen days, weekly security updates, and a pilot of two security releases per week on top.

The change that will actually bite: milestone deadlines arrive twice as fast

Most teams track web platform deadlines by milestone number, because that is how Chrome publishes them. "Removed in Chrome 158" was a date you could translate into roughly four weeks per milestone. That translation is now wrong by a factor of two.

The XSLT removal timeline is the cleanest illustration, because Chrome published it with both milestone numbers and dates:

Count the gap between Chrome 152 on 25 August 2026 and Chrome 158 on 17 November 2026. Six milestones, 12 weeks, two weeks apiece. Under the four-week cadence those same six milestones would have consumed 24 weeks and pushed removal into February 2027. The published dates already assume the new cadence, which means anyone who mentally converted "158" into "about six months away" has been wrong since March.

Two practical consequences follow. First, audit every milestone-numbered deadline in your backlog and re-derive its calendar date from the Chromium Dashboard rather than from arithmetic you did last year. Second, the escape hatches shrink in the same proportion. A deprecation trial or enterprise policy that buys you "18 milestones" is now 36 weeks, not 72. For XSLT that gap is real and already published: policy and trial coverage runs to Chrome 176 on 17 August 2027, and if you have RSS or Atom feeds relying on client-side transformation, our Chrome XSLT removal migration guide walks through the polyfill and server-side rendering options.

For context on how little of the web this particular removal touches: about 0.02% of page loads use XSLT at all, and fewer than 0.001% use XSLT processing instructions. The removal is driven by security rather than usage, with libxslt vulnerabilities including CVE-2025-7425 and CVE-2022-22834 cited by the Chrome engineers who published the plan, Mason Freed and Dominik Röttsches.

Extended Stable, and why it is not the answer for most teams

Extended Stable was introduced in 2021 for enterprise administrators and Chromium embedders who need more time to manage updates, and it keeps its eight-week cycle. The mechanics matter: the first two weeks of a milestone are identical between Stable and Extended Stable, and for the following six weeks Extended Stable receives weekly refreshes carrying the same security fixes as the Stable branch wherever that is technically possible.

The limitation is platform coverage. Extended Stable is available for managed devices on Windows and Mac. It is not supported on iOS or Android. If a meaningful share of your traffic or your workforce is on mobile Chrome, Extended Stable does not slow anything down for them, and your compatibility exposure runs at the full two-week pace regardless of what the desktop fleet does.

Google's own enterprise guidance for keeping fleets current is specific: apply the RelaunchNotification policy so users are prompted and eventually forced to restart for a pending update, use Extended Stable only for highly sensitive environments where software changes must be vetted, and use the Chrome Enterprise Core or Premium dashboard to track fleet-wide versions. That first item is the one most organisations skip, and it is the one that closes the gap between "patch released" and "patch applied".

Google is also working on removing the restart requirement entirely. Dynamic patching would replace background child processes such as the renderer and GPU process with updated binaries on the fly, using Chrome's multi-process architecture. In Chrome 150 a narrower version already shipped: on macOS, where applications commonly keep running with no windows open, Chrome now restarts itself automatically if an update is pending in that windowless state.

What to change in testing and CI

The honest summary is that nothing about this change is hard. It is that everything about it is scheduled, and schedules rot quietly.

Stop pinning browser versions by hand

A pinned ChromeDriver or Puppeteer version in a Dockerfile that someone bumped every four weeks now needs bumping every two. Move the version to a single variable resolved at build time and fail the build loudly when the resolved version drifts more than one milestone from production traffic. Manual bumps double in frequency and halve in reliability.

Add a beta lane, and give it a budget

Chrome recommends testing against the beta, which ships about three weeks before each stable release. Under the old cadence a weekly beta smoke run was arguably optional. With fourteen days between stable releases, beta is the only place a regression can be caught before it is in front of users. A nightly run of your critical-path suite against Chrome Beta is the highest-value single change on this list.

Instrument deprecations rather than reading changelogs

The Reporting API surfaces deprecation reports directly from production traffic, and the pattern is a few lines:

            new ReportingObserver((reports, observer) => {
  reports.forEach((report) => {
    // report.body.id names the deprecated feature, for example "XSLT"
    sendToTelemetry(report.body.id);
  });
}, {types: ["deprecation"], buffered: true}).observe();
          

That inverts the problem. Instead of a person reading two release notes a month and guessing what applies, your own traffic tells you which deprecated features you are still using and roughly when they disappear.

Enable the Legacy Technology Report for managed fleets

Chrome Enterprise can collect deprecated-feature usage across managed browsers and report it back, which is the fleet-level equivalent of the Reporting API snippet. It is the fastest way to find the internal line-of-business application nobody owns that still depends on something being removed in six milestones.

Re-time your release train against theirs

If you freeze changes during a Chrome stable week, you are now freezing every other week. That is not sustainable, so pick the opposite posture: keep shipping, and rely on beta-lane detection plus a fast rollback rather than on calendar avoidance.

India-specific considerations

Three points change the calculus for Indian teams.

Mobile share makes Extended Stable a partial answer at best. Because Extended Stable does not run on Android or iOS, an Indian consumer product with a mobile-heavy audience gets no cadence relief on the surface where most of its traffic sits. Plan compatibility testing around the two-week Stable cadence for mobile web regardless of what the desktop fleet policy says.

Change-management windows need rewriting, not stretching. Regulated environments in BFSI and healthcare typically run browser updates through a change advisory board on a monthly rhythm. A fortnightly cadence with weekly security refreshes, plus a pilot of two security releases per week, does not fit a monthly board. The workable pattern is a standing pre-approval for browser security updates with an exception process, rather than a per-release approval that guarantees your fleet runs behind.

Fleet telemetry is personal data. If you turn on the Legacy Technology Report or a Chrome Enterprise dashboard, you are collecting per-user browsing signals from employee devices. Under the Digital Personal Data Protection Act 2023 that is personal data with a fiduciary attached, and failure to keep reasonable security safeguards around it carries penalties reaching Rs 250 crore. Set a retention period, restrict access to the security team, and write the purpose down before you enable it, not after.

A five-week plan before 8 September

Week one: pull every milestone-numbered deadline your team tracks and re-derive the calendar date from the Chromium Dashboard. Expect at least one to have moved forward by months.

Week two: replace hardcoded browser versions in CI with a resolved variable, and add an alert when the resolved version drifts from production traffic by more than one milestone.

Week three: stand up a Chrome Beta lane running your critical-path suite nightly. Route its failures to the same place as production alerts, not to an unread channel.

Week four: deploy the ReportingObserver snippet to production and give it two weeks to collect. For managed fleets, enable the Legacy Technology Report in parallel.

Week five: take the deprecation list your own traffic produced, put calendar dates on it, and decide per item whether you migrate, take the origin trial, or take the enterprise policy. Anything relying on an escape hatch needs an owner and a date, because the hatches close on milestone numbers too.

Teams that run enterprise browser fleets should fold this into the same review as their browser security controls; the enterprise controls for agentic browsers piece covers the policy surface that has grown alongside the release cadence, and the wider 2026 web platform developer guide sets out the rest of this year's platform commitments.

FAQ

How eCorpIT can help

eCorpIT builds the release engineering around this kind of change: beta-lane test infrastructure, browser version resolution in CI, deprecation telemetry wired into the alerts your team already reads, and a change-management pattern that survives a fortnightly upstream cadence. We are CMMI Level 5, MSME certified and ISO 27001:2022 certified, and we design applications aligned with Digital Personal Data Protection Act 2023 requirements where fleet or usage telemetry is collected. If your QA schedule was built around four-week browser releases, talk to our engineering team before the first fortnightly milestone.

References

1. Get features faster with Chrome's two-week release cycle - Ben Mason and Deepak Ravichandran, Chrome for Developers, 3 March 2026.

1. Stronger with every update: how we're making Chrome and the web safer in the AI era - Chrome Security Team, Google, 30 July 2026.

1. Removing XSLT for a more secure browser - Mason Freed and Dominik Roettsches, Chrome for Developers, 29 October 2025.

1. Extended Stable channel - Chrome Enterprise and Education Help.

1. Chromium Dashboard release schedule - authoritative milestone dates.

1. Get started with origin trials - Chrome for Developers, including deprecation trials.

1. Feature deprecation and removal in Chrome - Chrome for Developers.

1. Chrome release notes - per-milestone changes.

1. Speeding up Chrome's release cycle - Chromium Blog, March 2021, the four-week change.

1. Early Stable releases - Chrome for Developers.

1. Chrome browser release channels - Chrome Enterprise and Education Help.

1. RelaunchNotification policy - Chrome Enterprise and Education Help.

1. Penalties and adjudication under India's DPDP Act 2023 - King Stubb and Kasiva.

Last updated: 4 August 2026.