Chrome 154 Brings Post-Quantum Crypto to Web Apps

Chrome 154 entered beta on September 2 with a change that could matter long after the browser version number disappears: developers can begin using browser-provided implementations of several post-quantum cryptographic algorithms through the Web Cryptography API. The same release also expands native CSS controls for carousels, adds a more flexible WebSocket constructor, and tightens security rules around Background Fetch.

Chrome 154 puts post-quantum cryptography inside Web Crypto

The most consequential developer change in Chrome 154 is the addition of post-quantum algorithms to the Web Cryptography API, the browser interface that lets websites perform cryptographic operations without implementing the underlying mathematics themselves. Google says the beta adds ML-KEM in the 768 and 1024 parameter sets, ML-DSA in the 44, 65 and 87 parameter sets, ChaCha20-Poly1305 and X-Wing. That gives web applications access to algorithms designed for a future in which sufficiently powerful quantum computers could threaten some of the public-key cryptography used today.

ML-KEM is a key-encapsulation mechanism: a method for two parties to establish a shared secret over a public network. The National Institute of Standards and Technology standardized ML-KEM as FIPS 203 in 2024 and describes it as a mechanism believed to remain secure against attackers with quantum computers. ML-DSA serves a different purpose, providing digital signatures that can be used to verify that data came from the expected signer and was not modified. Bringing both families into a browser API means developers can work with standardized post-quantum primitives without shipping their own cryptographic implementation.

Post-quantum support does not make every website quantum-safe

There is an important limit to what Chrome 154's Web Crypto additions actually accomplish. A browser exposing ML-KEM or ML-DSA does not automatically convert existing websites to post-quantum security. Applications have to be redesigned or updated to use those algorithms, and the systems communicating with them need compatible cryptographic support. A website that continues using conventional algorithms gains nothing simply because the browser underneath it has newer primitives.

The timing nevertheless gives developers a practical place to begin testing. NIST's finalized standards distinguish between key establishment and signatures, so applications can evaluate where each type fits rather than treating post-quantum cryptography as a single replacement switch. For developers building new authentication, encrypted messaging or sensitive data-transfer systems, browser-level support can reduce one of the barriers to experimenting with those standards.

CSS carousels need less JavaScript in Chrome 154

Chrome 154 also advances a very different part of web development: native CSS carousel controls. The scroll-marker-group property now supports links and tabs modes, allowing browser-generated scroll markers to behave more like navigation links or an accessible tab interface. The browser can therefore provide keyboard focus behavior and accessibility semantics that developers previously had to assemble with HTML, CSS and JavaScript.

This builds on a broader set of CSS carousel features that includes ::scroll-button(), ::scroll-marker and the :target-current pseudo-class. A developer can use these pieces to create a horizontally scrolling product gallery or content carousel while leaving much of the interaction logic to the browser. The advantage is not merely fewer lines of JavaScript; browser-managed interaction also gives the platform a clearer opportunity to keep scrolling, focus and accessibility behavior consistent.

There is still a compatibility catch. The relevant CSS features are not yet considered Baseline, meaning they do not work consistently across the browsers and versions covered by that compatibility standard. Developers supporting a broad audience should therefore treat Chrome 154 support as an opportunity to progressively enhance an existing interface, not as permission to remove every fallback.

WebSocket gets an options bag instead of a single extra argument

Chrome 154 changes how developers can configure a WebSocket connection. The WebSocket constructor, which opens a persistent two-way connection between a web page and a server, can now receive an options object as its second argument. The initial option is protocols, which provides the same basic subprotocol capability that was previously passed directly as the second argument.

That may sound minor, but an options object gives the API room to grow without continually changing its calling convention. Chrome's platform documentation also connects the broader options-bag work with Local Network Access behavior, where websites may need permission before communicating with services on a user's local network. For developers building browser applications that interact with local devices or services, the more structured API provides a foundation for those controls.

Background Fetch now has to respect CORS

Chrome 154 also tightens the security model for Background Fetch. Background Fetch lets a website request downloads that can continue while the user is not actively watching the page, which makes it useful for larger transfers. Starting with Chrome 154, those requests are subject to Cross-Origin Resource Sharing, or CORS, the browser security mechanism that controls whether a web page can request resources from another origin.

The change closes a potential policy gap. Google's release notes explain that Background Fetch must follow the same kinds of cross-origin and Local Network Access checks that apply to ordinary Fetch requests. Without that alignment, a site could potentially use the less common API as a route around restrictions that developers already expect the browser to enforce. For web developers, the practical result is that existing Background Fetch integrations should be tested against their server's CORS configuration rather than assuming behavior will remain identical.

Private Verification Tokens take aim at CAPTCHA friction

Chrome 154 also introduces a new origin trial for Private Verification Tokens. An origin trial is Google's controlled mechanism for letting developers test a browser feature before it becomes generally available. Private Verification Tokens are designed to let a website carry evidence of trust from an ordinary browsing session into private browsing mode, reducing the need to repeatedly challenge users with CAPTCHAs.

The idea addresses a specific problem with automated-traffic defenses. A site may trust a user during a normal session but have less information available when that user switches to private browsing. Instead of forcing the person through another challenge simply because the browsing context changed, the token mechanism is intended to transfer limited trust between those contexts. Because it is still an origin trial, developers should treat it as experimental rather than a finished web-platform dependency.

Chrome is changing its release rhythm at the same time

Chrome 154 arrives as Google begins moving Chrome Stable to a two-week release cycle. Google announced that Chrome 153 would begin the new schedule in September, cutting the interval between major browser milestones from four weeks to two. The company says the smaller releases should reduce the size of individual changes while allowing new web-platform capabilities to reach developers more quickly.

For web teams, that changes the maintenance equation. A four-week cadence already required regular beta testing; a two-week cadence makes continuous compatibility testing more valuable. Google recommends developers test their sites against beta releases, and Chrome 154 gives them several concrete reasons to do so: new CSS behavior, cryptographic APIs, WebSocket changes and stricter network security rules can all expose assumptions that remained invisible under older browser behavior.

Chrome 154 is more useful as a testing target than a checklist

Chrome 154's features point in different directions, but they share a common theme: more browser capabilities are moving into native platform APIs. CSS is taking over interaction that once required scripts, Web Crypto is gaining standardized post-quantum primitives, and network APIs are becoming more explicit about their security and configuration requirements. Developers get more capability from the platform, but they also inherit the responsibility of testing how those capabilities behave across browsers.

The immediate task is not to rewrite every web application for Chrome 154. It is to identify where these changes intersect with real projects: applications handling long-lived cryptographic data should investigate post-quantum options, carousel-heavy interfaces can test the new CSS primitives, and sites using Background Fetch should verify cross-origin behavior. Chrome's move to two-week releases makes that testing habit more valuable still, because the next meaningful web-platform change will arrive sooner than it used to.