Is Your Browser Quantum-Safe? Chrome, Safari, Firefox and Edge Compared

Abstract

Key Points at a Glance

1. Browser-by-Browser Comparison

The version numbers below are support milestones, the first releases in which the standardized hybrid became the default. They are not recommendations to install those releases; always run the current version of your browser.

Chrome

Google was the first of the four to ship hybrid post-quantum key exchange broadly. Chrome enabled an experimental hybrid based on the pre-standard Kyber draft by default on desktop in Chrome 124.^[2] When moving to the standardized construction, Google chose to replace the Kyber codepoint rather than advertise both, to avoid sending two large post-quantum key shares in every handshake.

Safari

Because Safari's support lives in Apple's system networking stack, the operating-system version is the deciding factor.^[5] A device that cannot be upgraded to version 26 does not gain post-quantum key exchange just because it runs Safari. Other browsers on macOS have their own support timelines.

Firefox

Mozilla documents an enterprise policy, PostQuantumKeyAgreementEnabled, which administrators can use to switch hybrid key agreement off.^[9] A managed Firefox installation may therefore behave differently from a personal one.

Edge

Microsoft Edge is built on Chromium and followed Chrome's migration. Starting with Edge 147, the policy that allowed organizations to disable post-quantum key agreement was removed.^[4] Enterprises that had used it to work around incompatible network equipment now need to fix that equipment instead.

2. What X25519MLKEM768 Actually Protects

Imagine an attacker records your encrypted HTTPS traffic today, perhaps a banking session, a medical portal login or a confidential business document, and stores it until sufficiently capable quantum computers become available. This is the harvest-now, decrypt-later threat. With classical key exchange alone, a future quantum computer could recover the session keys from the recorded handshake and decrypt everything that followed.

Apple explicitly describes its post-quantum TLS upgrade as protection against exactly this scenario: the browser and server negotiate a quantum-resistant method of establishing the connection's secret keys.^[5] The group all four browsers use is:

The hybrid design keeps the traditional component as a safeguard in case a weakness is found in the newer post-quantum algorithm, instead of replacing established cryptography outright. With a correct implementation, the hybrid remains secure as long as at least one of its two components remains secure.^[6]

It is also worth being precise about what ML-KEM does. ML-KEM does not encrypt the web page or the file you download. It establishes a shared secret, and that secret is used to derive keys for fast symmetric encryption (typically AES-GCM or ChaCha20-Poly1305) that protects the actual data. NIST standardized ML-KEM for precisely this key-establishment role.^[7] Symmetric ciphers with adequate key lengths are not meaningfully threatened by Shor's algorithm, so the key-establishment step is where the upgrade was needed. Our ML-KEM deep dive explains the lattice mathematics behind it.

3. Authentication Is the Unfinished Half

HTTPS does two jobs. Besides keeping traffic confidential, it must prove that you are talking to the genuine website rather than an impersonator. That proof comes from certificates and digital signatures, not from key exchange. A quantum-resistant key exchange does not automatically make the certificate system quantum-resistant.^[6]

These two threats are different in kind. A passive attacker who recorded an honestly established hybrid connection cannot decrypt it later, even with a quantum computer, as long as ML-KEM holds. An active attacker who can forge classical signatures at the time of the connection could present a fake certificate and impersonate the site.^[6] The second threat only becomes real once a cryptographically relevant quantum computer exists, which is why the industry has prioritized key exchange. It does not make authentication optional, because certificate ecosystems take years to change. Our Key Exchange vs. Digital Signatures analysis examines these different timelines.

What Is Happening with Post-Quantum Certificates?

The main obstacle is size. Post-quantum signatures and public keys are much larger than their elliptic-curve equivalents, and a typical HTTPS handshake carries several of them: the certificate chain, the server's handshake signature, and Certificate Transparency proofs. Simply replacing each signature with ML-DSA would add many kilobytes to every connection.

On 27 February 2026, Google announced work on Merkle Tree Certificates (MTCs), designed to make quantum-resistant HTTPS authentication practical without transmitting large conventional certificate chains on every connection. Google described a feasibility experiment with Cloudflare in which experimental MTC connections remain backed by traditionally trusted X.509 certificates, and its announced broader rollout stages extend into 2027.^[8]

4. Why an Updated Browser Is Not Enough

A post-quantum-capable browser is necessary but not sufficient. Three conditions outside the browser decide whether a given connection is actually protected.

The Website Must Negotiate It

"Enabled by default" means the browser offers the hybrid group; it does not mean the browser refuses classical-only servers. In TLS 1.3, the server chooses from the groups the client offers. Apple's documentation states explicitly that servers can select X25519MLKEM768 or another supported group.^[5] A classical connection does not trigger a warning or a padlock change.

The Browser Connection May Cover Only Part of the Journey

When a site sits behind a CDN or reverse proxy, the browser's TLS connection ends at that intermediary. The intermediary then opens a separate connection to the origin server. Post-quantum protection on the first hop says nothing about the second, and neither says anything about how the data is protected once it is stored.^[6]

Managed Networks Can Change the Result

Corporate and school networks can alter what your browser negotiates. TLS-inspecting proxies terminate your connection and open their own to the website. Microsoft and Apple both document compatibility problems with legacy network equipment and servers that mishandle the larger TLS handshake.^[4][5]

5. How to Check Post-Quantum Support

Check a Website with CipherScope

If you want to know whether a website is actually ready for post-quantum TLS, the easiest approach is to test the domain directly. Our CipherScope scanner checks the public cryptographic configuration of a domain and reports whether post-quantum support such as X25519MLKEM768 is visible.

Enter a domain name and CipherScope examines its HTTPS configuration, certificate chain and other publicly visible security properties, then gives a plain-language assessment of its current security and post-quantum readiness. No software or browser extension is required.

A server-side scan answers a different question from checking your browser. CipherScope tells you what the website publicly supports; it does not prove that one particular browser session negotiated the post-quantum group. If you want to inspect your own browser connection, expand the section below.

6. What This Means for Users, IT Teams and Site Operators

For individual users, the practical advice is simple: keep your browser and your operating system up to date. No settings need changing, and switching browsers for post-quantum reasons alone is unnecessary, because all four major browsers are now in the same category.

For IT and security teams, audit firewalls, TLS-inspection proxies and load balancers for correct handling of large ClientHello messages, and review any policy that disables post-quantum key agreement.

For website operators, the browser is ready and waiting; the server is now the limiting factor.

• Enable the hybrid on your TLS endpoint. Major CDNs already negotiate it by default. For self-hosted servers, TLS libraries such as OpenSSL 3.5 support X25519MLKEM768 and offer it in their default configuration.^[13]
• Keep classical fallback. Offer X25519MLKEM768 first and keep X25519 available for older clients.
• Check the second hop. If you use a CDN or reverse proxy, confirm whether the connection to your origin is also post-quantum.
• Verify from the outside. Test with the browser developer tools or a scanner after every configuration change.
• Plan for certificate migration. Track the MTC work and post-quantum certificate standards, and make sure your certificate automation can adapt when they arrive.

Our TLS vulnerability analysis covers related server-side configuration pitfalls.

7. Bottom Line

The next milestones to watch are server-side adoption, which determines how often the browser's capability is actually used, and post-quantum certificates, which will close the authentication gap. The first is well underway. The second has only just started.

Further Reading

For a closer look at the hybrid key-exchange mechanism now used by every major browser, and how its two components are combined, read our technical analysis:

How to Cite This Article

@misc{pqcryptography_browsers_pqc,
  author       = {{PostQuantumSecurity.org}},
  title        = {Is Your Browser Quantum-Safe? Chrome, Safari, Firefox and Edge Compared},
  year         = {2026},
  month        = sep,
  day          = {29},
  url          = {https://www.postquantumsecurity.org/publications/browsers_pqc.html}
}

References

1. Cloudflare. (2026). PQC support. Cloudflare SSL/TLS documentation. https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-support/
2. Google. (2024, September). A new path for Kyber on the web. Google Online Security Blog. https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html
3. Mozilla. (2024). Firefox 132.0 release notes. https://www.mozilla.org/en-US/firefox/132.0/releasenotes/
4. Microsoft. (2026). Archived release notes for Microsoft Edge Stable Channel. Microsoft Learn. https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-archive-stable-channel
5. Apple. (2025). Prepare your network for quantum-secure encryption in TLS. Apple Support. https://support.apple.com/en-us/122756
6. Cloudflare. (2026). Post-quantum cryptography (PQC). Cloudflare SSL/TLS documentation. https://developers.cloudflare.com/ssl/post-quantum-cryptography/
7. National Institute of Standards and Technology. (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. NIST CSRC.
8. Google. (2026, February 27). Cultivating a robust and efficient quantum-safe HTTPS. https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/
9. Mozilla. (2026). PostQuantumKeyAgreementEnabled. Firefox administrator reference. https://firefox-admin-docs.mozilla.org/reference/policies/postquantumkeyagreementenabled/
10. Cloudflare Research. (2026). Post-Quantum Key Agreement at Cloudflare. https://pq.cloudflareresearch.com/
11. Google. (2026). Privacy and security panel. Chrome DevTools, Chrome for Developers. https://developer.chrome.com/docs/devtools/security
12. Kwiatkowski, K., Kampanakis, P., Westerbaan, B., & Stebila, D. Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3. IETF Internet-Draft draft-ietf-tls-ecdhe-mlkem. https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
13. OpenSSL Project. (2025). OpenSSL 3.5.0 release. https://github.com/openssl/openssl/releases/tag/openssl-3.5.0