Browser post-quantum adoption

Browser post-quantum adoption describes how web browsers enabled post-quantum key exchange for TLS. Starting with Chrome experiments in 2023, hybrid groups pairing X25519 with ML-KEM became default in Chrome and Firefox during 2024, making browsers the largest single driver of post-quantum traffic on the web as of early 2026.

#Chrome timeline

Chrome moved first among major browsers. In August 2023, Google began enabling the hybrid group X25519Kyber768Draft00 in Chrome 116, explicitly citing the harvest now, decrypt later threat to traffic recorded before quantum computers exist. The staged experiment became a full launch in Chrome 124 in April 2024, when the Kyber hybrid was enabled by default for desktop users.

After NIST finalized ML-KEM, Google announced a migration from the draft Kyber group to the standardized X25519MLKEM768 in September 2024, shipping it in Chrome 131 in November 2024 and subsequently phasing out the pre-standard codepoint. The group itself is specified in the IETF draft draft-kwiatkowski-tls-ecdhe-mlkem; the mechanics of hybrid negotiation are covered under post-quantum TLS and hybrid cryptography.

#Firefox

Mozilla added support for the mlkem768x25519 hybrid in Firefox 128 in July 2024 and enabled it in subsequent releases. As of early 2026, current Firefox releases negotiate the ML-KEM hybrid by default, and Firefox and Chrome interoperate on X25519MLKEM768 against the same servers.

#Edge and Safari

Microsoft Edge shares Chromium's network stack and BoringSSL implementation, so the hybrid capability arrived with the shared code; Microsoft initially exposed it behind a flag and enterprise policy, and recent Edge releases enable post-quantum key exchange by default as of early 2026.

Safari is the most cautious of the four. As of early 2026, Apple had not announced default-on hybrid key exchange for Safari comparable to Chrome and Firefox, and publicly documented support remained partial, an asymmetry with Apple's early post-quantum work elsewhere (Apple iMessage PQ3). The gap concerns the browser's TLS defaults, not platform capability, and was widely expected to close.

#Server-side support

Browser defaults only produce post-quantum connections when servers negotiate the hybrid too. BoringSSL, the TLS library used by Google and by Cloudflare's edge, implements the hybrid groups, and large CDN operators terminated most early post-quantum traffic; Cloudflare reported over one third of human traffic to its network was post-quantum protected by March 2025. For the broader ecosystem, OpenSSL 3.5 (April 2025) added ML-KEM, ML-DSA, and SLH-DSA and included the hybrid group in its default TLS configuration, which is gradually carrying post-quantum support into distributions and servers that track OpenSSL (openSSL post-quantum support). Origin servers that have not updated simply fall back to classical groups, so measured adoption tracks the update cycles of the long tail.

#The ClientHello size problem

The rollout's main pain was not cryptographic but plumbing. An ML-KEM-768 encapsulation key adds 1184 bytes to the ClientHello, pushing it past the roughly 1400 bytes that fit in a single TCP segment on typical networks. A correct TLS implementation reads the full message regardless, but a long tail of servers and middleboxes assumed the entire ClientHello arrives in the first read, and these failed when the message split across packets. The issue, documented at tldr.fail, caused connection failures during Chrome's rollout and forced fixes across server software and network appliances. The episode is frequently cited as a preview of PKI migration to post-quantum: if 1 KB in the handshake broke fragile assumptions, multi-kilobyte post-quantum certificate chains will find more. It also illustrates why browsers rolled out gradually with kill switches, and why cryptographic agility, the ability to change algorithms without breaking deployments, is treated as a first-class migration requirement.