The problem this fixes
Chrome 153, currently in beta ahead of a planned September 8, 2026 stable release, replaces the browser's XML parsing engine with one written in Rust for most real-world use cases. The engine it replaces, libxml2, is a C library, and C code that parses untrusted input from the open web is a recurring source of memory-safety bugs: use-after-free errors, memory corruption, and the like. libxml2 specifically has racked up a run of them recently, including a use-after-free flaw (CVE-2025-49794), a memory corruption bug (CVE-2025-49796), and two recursion-related denial-of-service issues (CVE-2026-0989 and CVE-2026-0990). Rust's compiler enforces memory safety at build time, which eliminates that entire class of vulnerability by construction rather than by patching each instance as it's found.
The new parser covers four scenarios where Chrome parses XML: the DOMParser API, XMLHttpRequest's responseXML property, navigating directly to a standalone SVG image, and loading an SVG as an external image resource. One case is deliberately excluded for now: XSLT, the XML transformation language, still runs through the old path. Google has been separately winding XSLT down as part of the same security push, so the Rust parser rollout reads as the first step in a longer plan to retire the C-based XML stack rather than the whole job at once.
New HTML elements for camera and microphone access
Chrome 153 also adds two new HTML elements, <camera> and <microphone>, that give sites a declarative way to request just one type of media capability. They build on the <usermedia> element Chrome introduced in version 151, which handles combined audio-and-video capture; the new elements are for the narrower and arguably more common case where a site only needs one or the other; a voice memo app that has no use for a camera feed, for example. They inherit the same security model as <usermedia>, including strict limits on how they can be styled and the same built-in path for a user to recover from an accidentally denied permission, so this is an ergonomics addition on top of already-shipped infrastructure rather than a new permission system.
Smaller platform additions
A handful of other features land in this release:
- WebGPU buffer_view: lets a WGSL (WebGPU Shading Language) shader reinterpret one uniform, storage, or workgroup variable as several logical variables of different types, useful for packing data more efficiently on the GPU.
- WebAudio renderSizeHint: a new parameter on AudioContext and OfflineAudioContext that lets developers choose the audio render quantum size, either the existing 128-frame default or a size the hardware handles more efficiently.
- TC39 iterator helpers:
Iterator.join()concatenates the contents of an iterator into a string, and a companion "iterator zip" capability allows iterating over several iterators together in lockstep. - IAMF decoding: Chrome can now decode IAMF (Immersive Audio Model and Formats), an open, royalty-free format for spatial audio.
- JS Self-Profiling API marker field: an origin-trial addition that tags each call-stack sample the profiler captures with what kind of work was happening, script execution, garbage collection, style calculation, layout, paint, or other, making profiler output easier to interpret without cross-referencing timestamps by hand.
What's being removed
Three things are going away in 153: the non-standard _current value for navigation targets, the document.requestStorageAccessFor API, and the Related Website Sets framework. None of these were widely used standards-track features, so the practical impact should be limited to sites specifically relying on them.
Rollout timeline
The desktop beta build (153.0.8010.12) reached Windows, macOS, and Linux on August 26, 2026, following an initial beta announcement on August 20. An Android build (153.0.8010.18) began rolling out August 27, with iOS beta and stable builds following in the same window. Google's stated target for the stable channel across desktop platforms is September 8, 2026.
What it means for developers
If your site parses XML, renders standalone SVGs, or reads XMLHttpRequest's responseXML property, it's worth testing against Chrome 153 beta before the stable rollout, not because the new parser is expected to break standards-compliant behavior, but because edge cases and error handling can shift slightly whenever a parsing engine is swapped out wholesale. If you still rely on XSLT anywhere in production, treat that as a deprecation warning: it's on a separate but related path out of the browser, and migrating off it now avoids a scramble later. Teams building camera- or microphone-only capture UI have a legitimate reason to try the new <camera> and <microphone> elements instead of requesting combined media access through <usermedia> or getUserMedia and then discarding the stream you didn't need, since asking for only what you use is both simpler code and a better privacy story for users. Everyone else can treat this release as routine maintenance: the XML parser change is a security upgrade you benefit from without doing anything, and the rest of the additions are targeted enough that most sites won't touch them.
