Chrome / Chromium
Is PQC enabled? — quick check
Chrome / Edge / Brave (DevTools — fully local)
# 1) Open a TLS 1.3 site you trust (your own, or any HTTPS host).
# 2) Press F12 → Security tab → click the origin under "Main origin".
# 3) Read "Connection" — it lists the negotiated key exchange group by name.
#
# Capability flag (offline): chrome://flags#enable-tls13-kyber
# (renamed enable-tls13-mlkem in Chrome 131+)Expected when PQC is ON
Connection - protocol: TLS 1.3,
key exchange group: X25519MLKEM768,
cipher: AES_256_GCMWhat you'll see when PQC is OFF
Connection - protocol: TLS 1.3,
key exchange group: X25519,
cipher: AES_256_GCMDevTools reads the negotiated group from the live connection state in the renderer — no network call leaves the page. Firefox: about:config → security.tls.enable_kyber = true; Safari has no PQ in WebKit yet.
Chrome shipped X25519Kyber768Draft00 enabled by default in version 124
(April 2024) and migrated to the standardized X25519MLKEM768 in version 131
(Nov 2024). Edge, Brave, Opera, Vivaldi, and any current Chromium-based browser inherit
this behavior.
How to verify in Chrome
- Open the page over HTTPS.
- Open DevTools → Security tab → look at the connection details.
- Or visit pq.cloudflareresearch.com — it shows the negotiated key-agreement algorithm.
Enterprise policy
Hybrid PQC is controlled by the
PostQuantumKeyAgreementEnabled policy. Default is true. If
legacy middleboxes break hybrid handshakes you can disable it temporarily, but the right
fix is to update those middleboxes — they're misclassifying the larger ClientHello.
Flags (advanced)
chrome://flags/#enable-tls13-kyber— legacy flag, removed in recent builds.chrome://flags/#use-ml-kem— controlled the migration from Kyber to ML-KEM, removed once ML-KEM became default.