Full-stack QUIC & HTTP/3 analysis β post-quantum hybrid TLS, QUIC v1/v2, multipath, WebTransport, MASQUE, certificate chain & performance metrics
HTTP/3 with QUIC and WebTransport delivers faster page loads and mandatory TLS 1.3 encryption. Our scanner uses native QUIC libraries to extract real peer-advertised metadata, from transport parameters and HTTP/3 SETTINGS to certificate chains and post-quantum key exchange, and grades every site on a 5-tier scale (A++, A+, A, C, F). Curious how a scan actually works on the wire? Read Anatomy of a QUIC Connection, our whitepaper that replays one real scan packet by packet.
The scanner extracts detailed metadata including real peer-advertised QUIC transport parameters, HTTP/3 SETTINGS (QPACK, Extended CONNECT, datagrams), server implementation fingerprinting (identifying Cloudflare, Google GFE, Facebook mvfst, Fastly H2O, and more), connection metrics (handshake time, TTFB, RTT, GSO, probe timeouts), certificate chain analysis (OCSP stapling, Certificate Transparency, root CA), and TLS extension analysis. The 5-tier grading requires post-quantum hybrid key exchange for the top tier and produces intelligent per-scan recommendations.
wq-vvv-01 β a different transport from WebTransport over HTTP/3, and one QUIC answers definitively because ALPN negotiation must succeed for the handshake to complete
Analysis target: by default, the exact hostname you enter — the analyzer grades that host's own response and does not follow redirects. If a site redirects (e.g. example.com → www.example.com, or to a different domain), HTTP/3 may live on the target, not the apex. Enable Follow redirects — the checkbox above — to instead analyze the final destination; the result clearly shows which host was actually analyzed.
Try these examples:
?url=pqcrypta.com
/pqcrypta.com
Enter URL above
Ultimate: HTTP/3 a browser can find, 0-RTT shown to be off, WebTransport, and a post-quantum hybrid key exchange negotiated.
Excellent: HTTP/3 with QUIC protocol. 0-RTT disabled for maximum security.
Good: HTTP/3 with QUIC protocol. Either 0-RTT is enabled (replay attack risk), or this scan could not establish whether it is β A+ needs 0-RTT shown to be off.
Misconfigured: HTTP/3 is served but never advertised, or advertised but unreachable.
Failed: No HTTP/3 support detected. Using legacy HTTP/2 or HTTP/1.1 protocols only.
How common each capability is among the origins this scanner has actually connected to. Every rate below is shown with the population it was measured over, because they are not the same population: a QUIC transport parameter can only be read where a QUIC handshake completed, a TLS group is negotiated over TCP as well, and a DNS record is resolved without connecting to anything.
Loadingβ¦
Each rung is a narrower question than the one above it, so the fall between rungs localises where a technology stops being available: at the transport, at the handler, or at the door. Advertising a capability and letting an anonymous client use it are not the same claim, and the gap between them is the finding.
Only implementations with at least ten domains in the sample. A percentage over four domains is not a rate.
| Implementation | Domains | HTTP/3 | PQ key exchange |
|---|
A field that is empty on every scan reads from outside as a measured absence. These are the ones we never look at, and why β so a null can be told apart from a finding. Grouped by reason, because most of them are not limits on what is knowable: they are work we have not done, and they say what the work is.
These figures are free to reuse under CC BY 4.0, credited to the PQ Crypta Post-Quantum QUIC & HTTP/3 Analyzer. Every figure, as JSON: api.pqcrypta.com/http3-scanner/corpus.
Everything on this page is rendered from four JSON endpoints on api.pqcrypta.com. The page is one client of them, not the only one β a script, a CI job or a monitoring check reads exactly the same fields the panels above do, with no browser and no HTML parsing.
| Endpoint | Auth | Returns |
|---|---|---|
POST /http3-scanner/scan |
API key | One scan of one origin β the whole result object behind every panel above, including grade, grade_reason, quic_transport_params, tls_extensions, not_measurable and the probe_version / grader_version stamps that say which instrument produced it. |
GET /http3-scanner/corpus |
none | Capability adoption across the scanned corpus, each rate with its own denominator, plus the derivation contract version the figures were computed under. |
GET /http3-scanner/timeline |
none | The history behind Posture Over Time for one domain: what changed between observations, with the runs where nothing moved collapsed. Takes ?domain= and an optional limit. A scan describes one observation; this is the series, and no scan response can carry it. |
GET /http3-scanner/stats |
none | The public directory: grade distribution and the scans listed in each grade card. |
Send the key as X-API-Key. Any key carrying the general endpoint scope works; keys are issued per account. A scan makes several real connections to the origin you name and can take tens of seconds, so allow a generous client timeout β set --max-time well above the 40-second scan ceiling rather than at it.
curl -s https://api.pqcrypta.com/http3-scanner/corpus
curl -s --max-time 120 -X POST https://api.pqcrypta.com/http3-scanner/scan \
-H 'Content-Type: application/json' \
-H "X-API-Key: $PQCRYPTA_API_KEY" \
-d '{"url":"example.com"}'
No browser User-Agent is required or expected on these paths β a default curl, python-requests or SDK agent string is served normally. No value on this page is measured in its JavaScript; every panel is rendered from a response. The page derives presentation from those fields β counts like “9 of 10 sent”, units, and formatting β but nothing it shows was observed anywhere except in a response above.
Every panel on this page comes from one of those four, Posture Over Time included.
HTTP/3 is the latest version of the Hypertext Transfer Protocol (RFC 9114), standardized by the IETF in June 2022. Unlike HTTP/1.1 and HTTP/2 which run over TCP, HTTP/3 uses QUIC (Quick UDP Internet Connections) as its transport layer. QUIC operates over UDP with mandatory TLS 1.3 encryption built directly into the transport protocol, combining the transport and cryptographic handshakes into one round trip and recovering lost packets per stream rather than stalling every stream behind one retransmission. How much of a speed difference that makes depends on the loss and latency of the path and on how much of the page is fetched concurrently.
Faster Connections: QUIC combines the cryptographic handshake with connection establishment (1-RTT), compared to TCP+TLS requiring 2-3 round trips. 0-RTT resumption enables instant reconnection for repeat visitors. Zero Head-of-Line Blocking: Independent streams prevent one slow resource from blocking others, critical for modern web applications with hundreds of assets.
Mandatory Encryption: Unlike HTTP/2 where TLS is optional, HTTP/3 requires TLS 1.3, the most secure version with forward secrecy and modern cipher suites. Transport Metadata Protection: QUIC encrypts packet numbers, connection IDs, and other transport metadata that TCP exposes in plaintext, defending against traffic analysis, fingerprinting, and network-level attacks.
Connection Migration: Unique connection IDs allow seamless handoff when switching networks (Wi-Fi β cellular) without dropped connections or re-authentication. Improved Loss Recovery: Per-stream acknowledgments and more accurate RTT estimation provide better performance on lossy networks (mobile, satellite, public Wi-Fi). WebTransport: Bidirectional streaming over QUIC enables real-time applications like gaming, video conferencing, and collaborative editing.
The third version of HTTP (RFC 9114, June 2022). It runs over QUIC instead of TCP, so it needs a UDP path to the server, and TLS 1.3 is built into the transport rather than layered on top.
A transport protocol over UDP (RFC 9000) with TLS 1.3 built into its handshake (RFC 9001). It sets up the connection and the encryption in one round trip, carries independent streams so a lost packet stalls only its own stream, encrypts packet numbers and most of the transport metadata TCP sends in the clear, and lets a connection move between networks. QUIC version 2 (RFC 9369) is the same protocol under a new version number, so middleboxes cannot ossify on version 1.
A browser reaches a site over TCP first unless the site tells it otherwise: in an Alt-Svc response header naming h3, or in a DNS HTTPS record (RFC 9460) with alpn h3, which lets it use HTTP/3 from the first connection. The scanner checks both. A server that serves HTTP/3 but advertises it nowhere is never reached over it, and one that advertises HTTP/3 but does not answer over UDP makes browsers try a path that fails; both grade C.
A++: HTTP/3 a browser can find, 0-RTT shown to be off, WebTransport, and a post-quantum hybrid key exchange negotiated. A+: HTTP/3 a browser can find, with 0-RTT shown to be off. A: HTTP/3 a browser can find, but 0-RTT is on (a replay risk) or could not be shown to be off. C: misconfigured, with HTTP/3 served but never advertised, or advertised but unreachable. F: no HTTP/3.
It lets a returning client send its first request together with the handshake, saving a round trip, but that early data has no protection against replay (RFC 8446, section 8): an attacker who captures it can send it again, and a request that changes something can run twice. The scanner grades A+ or A++ only when it has shown that the server does not offer 0-RTT.
A browser API for low-latency, two-way communication over HTTP/3, with many streams and unreliable datagrams on one QUIC connection, for games, live media and collaborative tools. The scanner opens a WebTransport session on ports 443 and 4433, or on a port you give, and separately tests WebTransport over a dedicated QUIC connection (ALPN wq-vvv-01).
Yes. QUIC uses the TLS 1.3 handshake, so the same hybrid groups work, such as X25519MLKEM768 (RFC 10024), which current browsers offer by default. The scanner records the key exchange the server negotiates, and A++ requires a post-quantum one. The PQC Readiness Scanner (pqcrypta.com/pqc-ready/) tests every key-exchange group a server accepts.
It connects over HTTP/3, HTTP/2 and HTTP/1.1, reads the Alt-Svc header and the DNS HTTPS record, and records what each connection negotiated: QUIC version, transport parameters, TLS key exchange, HTTP/3 SETTINGS and the certificate chain. It then tests the extensions one at a time: 0-RTT, WebTransport, a MASQUE CONNECT-UDP session relaying real UDP, an RFC 9218 PRIORITY_UPDATE frame, and QUIC multipath by opening a second path. Every result carries the version of the scanner that measured it.
QUIC v2 (RFC 9369, 2024) is an anti-ossification revision, not a feature release. It has the same capabilities as QUIC v1 (RFC 9000) but changes version codepoints, salts, and TLS labels so endpoints and middleboxes keep exercising version negotiation instead of hard-coding "QUIC = v1." It adds no new transport features. The genuinely new capabilities below are separate extensions, each on its own track β they are not part of QUIC v2:
Sources: IETF QUIC Working Group β RFC 9369 (QUIC v2), RFC 9002 (loss recovery / congestion-control baseline), draft-ietf-quic-multipath, draft-ietf-quic-ack-frequency. See the Technology Verification Status table below for per-feature standardization state.
Future HTTP/3 enhancements being discussed in IETF HTTP WG and research communities:
Source: IETF HTTP WG, draft-ietf-httpbis-*, W3C WebTransport specifications
Some research is exploring post-HTTP models entirely, rethinking how the internet routes and delivers content:
Source: IRTF ICNRG, ACM ICN workshops, Named Data Networking project
WebTransport overlaps WebRTC's data channels and is a simpler fit for client-to-server streaming, but it is not a replacement: WebRTC also carries peer-to-peer connectivity, media capture, echo cancellation and the ICE/STUN/TURN machinery for traversing NAT, none of which WebTransport provides or plans to. Where the two are compared fairly is server-mediated data transport. Directions under discussion:
Source: W3C WebTransport WG, IETF QUIC WG discussions, Chrome/Firefox roadmaps
Not standards yet, but active research in academia and industry (Google, Meta, Cloudflare):
Source: ACM SIGCOMM, Google Research (Remy, PCC Vivace), Meta's Robustness team
QUIC is expanding beyond HTTP/3 into databases, microservices, and system infrastructure:
Source: RFC 9250 (DNS over QUIC), gRPC roadmap, CNCF service mesh projects
| Layer | Current Cutting Edge | Next / Future | Status |
|---|---|---|---|
| Transport | QUIC v1 & v2 (RFC 9369), Multipath, ACK Frequency | FEC, newer congestion control (BBRv3/Copa) | v1+v2 live here drafts live here |
| HTTP | HTTP/3 (RFC 9114) | Partial reliability, better prioritization | Design Phase |
| Real-Time | WebTransport | Multipath + media + P2P | Active Dev |
| Architecture | Client/Server | Content-centric, P2P | Research |
| Performance | TLS 1.3 + QUIC | AI-optimized transport | Research |
| Beyond Web | HTTP/3 + WebTransport | QUIC for databases, RPC, IoT | Early Impl |
The technologies coming next are:
Timeline: QUIC v2 RFC 9369 (2024) β live on this server's HTTP/3 and WebTransport endpoints; Multipath QUIC still an active IETF WG draft industry-wide (this site's own server already implements full real server-side support - see the Verification Status table below); HTTP/3 extensions (2026-2027), AI-optimized (2027-2030), Content-centric networks (2030+)
Current standardization and implementation status of emerging technologies. The "supported here" badge means this scanner has genuine testing capability for that technology against any site you scan; "partial here" means part of the question is answerable and the rest is not, with the row saying which part. pqcrypta.com's own server also implements QUIC v2, CONNECT-UDP, ACK Frequency, RFC 8879 certificate compression and full Multipath QUIC β scan this site and those validate as real, rather than only demonstrating that the scanner can probe for them.
| Technology | Status | Evidence |
|---|---|---|
| QUIC v2 supported here | β Standardized | RFC 9369 |
| Multipath QUIC supported here | β Not standardized | draft-ietf-quic-multipath-21 |
| QUIC FEC | β Research only | No RFC |
| HTTP/3 partial reliability | β Research only | No active I-D |
| WebTransport multipath | β Not implemented | No browser support |
| AI congestion control | β Research only | SIGCOMM papers |
| DNS over QUIC | β Standardized | RFC 9250 |
| MASQUE CONNECT-UDP supported here | β Standardized | RFC 9298 |
| WebTransport over QUIC supported here | β Not standardized | draft-vvv-webtransport-quic-02 (ALPN wq-vvv-01) |
| RFC 8879 certificate compression supported here | β Standardized | RFC 8879 β the scanner reads which algorithm an origin compressed with, and this server compresses its own chain: 3,435 bytes to 2,376 with zlib, about 1 KB off every full handshake |
| RFC 9345 delegated credentials partial here | β Standardized | RFC 9345 β certificate authorisation is read; whether a handshake used one needs a TLS stack offering extension 34 |
| QUIC ACK Frequency supported here | β οΈ Draft | draft-ietf-quic-ack-frequency |
| QUIC for databases | β οΈ Experimental | Cloudflare prototypes |
| QUIC service mesh | β οΈ Experimental | CNCF projects |
| Content-centric networking | β Research only | ICNRG |