Chrome 155 Brings JPEG XL and Post-Quantum WebCrypto

Chrome 155 adds post-quantum algorithms to WebCrypto. That is the part of this release worth planning around, and it is the part most coverage of the milestone skips past on the way to the image format. The Chrome Platform Status release notes for 155 list both changes, along with a shorter tail of CSS, windowing and policy work.

Post-quantum crypto arrives in the platform, not in a library

The WebCrypto update adds ML-KEM 768 and 1024 for key encapsulation, ML-DSA 44, 65 and 87 for signatures, ChaCha20-Poly1305 for symmetric encryption, and X-Wing, a hybrid key encapsulation mechanism. The release notes describe these as standardised by NIST.

The consequence is a dependency you no longer ship. A site that wants a post-quantum or hybrid handshake has had to bundle a WebAssembly library, keep it patched against its own advisories, and accept the cost of running crypto that the browser cannot optimise. With ML-KEM and ML-DSA in WebCrypto, that work moves into the engine and arrives with browser updates. For a small team that is the difference between a migration it can staff and one it keeps deferring.

There is a second reason the browser matters here. A post-quantum migration is not one change but a chain: servers, certificates, load balancers, client libraries and the browser. An application team can replace everything it controls and still be stuck if the user's browser cannot complete the handshake. Platform support removes that link from the chain, which is the difference between a migration that can be scheduled and one that waits on a third party's roadmap.

Why this matters more than an image format

Symmetric encryption does not fall to a quantum computer in the way key exchange does, which is why the pressure sits on the handshake. Traffic recorded today can be decrypted later if the key exchange that protected it turns out to be breakable, so the migration clock started before any useful quantum machine existed.

X-Wing is the practical piece. A hybrid mechanism combines a post-quantum algorithm with a classical one, so the connection stays safe if either holds up. That is also the reason you should not expect a single flag flip. Algorithms in WebCrypto are selected by name at call time, so nothing changes in existing code until you ask for the new ones, and anything you keep for older browsers has to coexist with them for a while.

JPEG XL comes back with a Rust decoder

Blink gains decoding support for image/jxl, implemented with jxl-rs, which the release notes call "a memory-safe pure Rust decoder". JPEG XL is ISO/IEC 18181 and supports progressive decoding, wide colour gamut, HDR, high bit depth and animation. Chrome had dropped the format; this puts decoding back in the browser, which is the half web authors were waiting for.

Serving image/jxl is a pipeline question rather than a markup question. You need an encoder in your build or your image service, a decision about how the format is selected for each visitor, and a fallback for every browser that does not decode it yet. Because support is additive, that fallback is the format you already serve, so the risk in testing it is low and the risk in switching over early is limited to wasted bytes. Measure the bytes before you rewrite the pipeline around them.

The 50 percent compression figure is not Google's

Coverage of the change reports JPEG XL compressing roughly 50 percent better than JPEG. That figure comes from an outlet's summary, not from the release notes, and compression ratios depend on the corpus, the quality target and whether the comparison is against a modern JPEG encoder or an old one. If you are considering it for a production image pipeline, encode a sample of your own images at the quality you actually ship and measure the bytes. The browser is only the decoder; the encoder settings and the CDN support are your side of the problem.

The rollout status is not settled

The release notes page that describes all of this is labelled Preview on Chrome Platform Status, while the same milestone lists a scheduled stable release of 6 October 2026. Feature lists on that page hold up; the Preview label means the rollout should not be treated as a fact you can hang a launch date on. Check the Chrome release blog before you depend on either feature in production, and expect the usual staged delivery to users.

What to check before you depend on either

For crypto, take an inventory of where you do key exchange and signatures. If you use a WASM post-quantum library, work out which browser versions you would give up by moving to WebCrypto, and keep a classical path for everything older. For images, there is nothing to break: JPEG XL is additive, so existing JPEG and WebP keep working while you decide.

The crypto inventory is the part worth doing now, before the algorithms are everywhere. Write down which call sites establish a shared secret, which ones sign, and which library or platform primitive each one uses today. That list is the migration plan, and it is much easier to build while the answer is still "the old thing" everywhere. A team that waits until a compliance deadline is close will be editing those call sites under time pressure with a release train already full.

The shorter items in the same release

Additional Windowing Controls, behind the window-management permission, let an installed app call maximize(), minimize(), restore() and setResizable(), with display-state and resizable as new CSS media features. JavaScript gets Import Text, the TC39 proposal for import … with { type: "text" }. CSS gains symbols() inline counter styles, text-decoration-skip-spaces, and margin-trim:

/* Block and multicol containers only; flex and grid support was removed. */
.card { margin-trim: block; }

The Digital Credentials API gains issuance support. New restrictions on chrome.debugger hosts and screenshots enforce enterprise ExtensionSettings and DisableScreenshots or DLP policies. PredefinedColorSpace adds srgb-linear and display-p3-linear. A media-playback-while-not-visible permission policy lets a page pause audible media in hidden iframes.