Google released Chrome 153 to the Stable channel on 8 September for desktop, Android and iOS. It is the first version to ship under the two-week release cycle Google announced in March, and its release notes, published the same day, show what a fortnightly Chrome looks like in practice: two new HTML elements for camera and microphone access, a memory-safe XML parser written in Rust, a handful of CSS and JavaScript additions, and a deprecation list that quietly closes the book on most of the Privacy Sandbox.
Chrome 154 follows on 22 September, according to 9to5Google, which also reports Google’s framing of the faster cadence: fixes reach users sooner, and a smaller release makes it easier to isolate a regression when one slips through.
Camera and microphone become HTML elements
The headline developer feature is a pair of what Google calls capability elements. The <camera> element requests video capture and the <microphone> element requests audio capture. Rachel Andrew’s “New in Chrome 153” post describes them as “declarative, user-activated HTML controls”: the browser draws the button, the user has to click it, and only then does a permission prompt appear or a stream start.
They build on the <usermedia> element that shipped in Chrome 151 in June. That earlier post, by Mari Viana and Minh Le, explained the reasoning. A click on a browser-controlled button is “a trusted signal of intent”, which matters because permission requests fired from a script with no obvious user action are the ones browsers increasingly block or bury. The element also carries a recovery path: if a user denied camera access months ago, tapping the element “triggers a specialized recovery flow that lets you re-enable your camera or microphone instantly on the page, without navigating complex browser settings.”
The styling rules are deliberately strict so that the button cannot be disguised: the <usermedia> post lists a minimum text contrast of 3:1, no transparency or negative margins, and transforms limited to 2D translation and proportional scaling. The new single-capability elements keep, in the words of the beta post, the “identical security model, strict styling constraints, and built-in permission recovery path as the <usermedia> MVP.”
Memory-safe XML parsing
Chrome 153 moves XML parsing for several common paths to a Rust implementation. The release notes name DOMParser, the responseXML property of XMLHttpRequest, and standalone and external SVG images. XSLT scenarios are not covered by this change. Google’s stated goal, per the beta post, is to “eliminate potential memory corruption bugs while maintaining full compatibility with existing web specifications.”
For a site owner the practical relevance is SVG. Logos, icons and illustrations delivered as SVG files now pass through the new parser. Google says compatibility is maintained, and there is no action to take, but if an SVG asset renders differently after the update, this is the change to look at first.
CSS and JavaScript additions
Two CSS changes address scrolling. The overflow property now accepts a scrollable value together with clip, so overflow: scroll clip creates a scroll container on one axis while the other axis stays clipped in place. The release notes note that this lets position: sticky be constrained by different ancestor scroll containers per axis. A new scroll-axis-lock property lets a developer tell the browser not to lock a scroll gesture to a single axis when diagonal scrolling is wanted.
JavaScript gains two TC39 proposals. Iterator.prototype.join() concatenates an iterator’s output into a string, mirroring Array.prototype.join(). Joint Iteration adds Iterator.zip() and Iterator.zipKeyed(), which walk several iterables in step and yield arrays or keyed objects; the modes are “shortest” by default, “longest” with optional padding, and “strict”, which throws a TypeError when lengths differ.
Elsewhere, Chrome 153 decodes the Immersive Audio Model and Formats container, an open, royalty-free spatial-audio format, through Media Source Extensions, WebTransport connections can carry custom HTTP headers, and the Long Animation Frames API now reports from web workers.
Privacy Sandbox reaches the deprecation list
Chrome 153’s notes state that the Protected Audience API, the Shared Storage API, the Attribution Reporting API, Related Website Sets and document.requestStorageAccessFor are each “planned for deprecation and removal”. The reason given for Related Website Sets is that it was designed for a browser without third-party cookies, and Chrome has decided to keep them. The beta post from 20 August already listed Related Website Sets and requestStorageAccessFor as removals.
None of this is a surprise. On 17 October 2025 Anthony Chavez, Google’s VP for Privacy Sandbox, announced that Google was retiring ten Privacy Sandbox technologies, including Topics, Protected Audience, Attribution Reporting, Private Aggregation with Shared Storage, and Related Website Sets, citing “ecosystem feedback about their expected value and in light of their low levels of adoption.” That post promised the details would “follow Chrome and Android processes for phasing out these technologies.” Chrome 153 is where those processes become visible in a release note.
What it means for your business
If your site uses a camera or microphone, the new elements are worth adopting early. Identity checks, virtual try-on, a “scan your document” flow: each of these today opens with a JavaScript call and a permission prompt that many users reflexively dismiss. A browser-drawn button that the user chooses to click, with a built-in path to recover a previously denied permission, addresses the exact moment where such flows lose people. Chrome is the only browser shipping this today, so it must be progressive enhancement: keep the existing getUserMedia path as the fallback.
If your ad stack or analytics ever integrated a Privacy Sandbox API, it is time to remove that code. Attribution Reporting, Protected Audience and Shared Storage integrations were mostly done by ad-tech vendors rather than by site owners directly, but tags and consent configurations that reference them still exist. Ask your vendor what happens when the APIs disappear, and make sure your conversion measurement does not silently depend on one of them. Third-party cookies stay, which means the measurement setup you had before the Sandbox is the one that remains.
Related Website Sets affected a specific group: companies running several domains that share a login or a cart. If you declared a set so that cookies could flow between your brand domains, that mechanism is being withdrawn. The Storage Access API itself remains; only the set-based shortcut and requestStorageAccessFor go. Check any cross-domain sign-in or checkout now rather than when a customer reports it.
Nothing in this release should break a normal marketing site. The XML and SVG change is meant to be invisible, the CSS additions are opt-in, and the JavaScript methods are new rather than changed. The habit we recommend, and build into every website we maintain, is unchanged from last week: one browser profile on the Beta channel, and a walk through your forms, checkout and any camera flow once a fortnight. Chrome 154 Beta is already out; it becomes Stable on 22 September.
Our reading is that Chrome 153 is a modest release with one important signal. The features are incremental, but the deprecation list confirms that the browser is finished trying to replace third-party cookies with its own advertising APIs. For a business, that removes a variable that has hung over web analytics and advertising plans for six years. Plan on cookies, consent and first-party data, and treat anything labelled Privacy Sandbox as legacy.
