HTTP/3 and QUIC support probe
Check whether a public URL supports HTTP/3 and QUIC. The tool fetches the response headers through the PeopleAreGeek server, parses the alt-svc directive, identifies the QUIC versions advertised (h3, h3-29, h3-28…), spots 0-RTT readiness, recognises the server software (Cloudflare, Fastly, LiteSpeed, nginx-quic, h2o) and explains how to enable HTTP/3 if the site does not yet support it. Useful when migrating a stack, optimising mobile performance or auditing a vendor.
The probe relies on the alt-svc response header that servers use to advertise alternative protocols. The first request often arrives over HTTP/1.1 or HTTP/2; HTTP/3 is then negotiated on the second connection. A fresh probe may need a follow-up after a few seconds.
What HTTP/3 and QUIC change for a public site
HTTP/3 is the latest revision of the HTTP family. Unlike HTTP/1.1 and HTTP/2 which both run over TCP, HTTP/3 runs over QUIC, a UDP-based transport that was standardised as RFC 9000 in 2021. QUIC removes the head-of-line blocking that limits HTTP/2 on lossy networks, opens connections faster thanks to a combined cryptographic and transport handshake, and supports 0-RTT resumption so repeat visitors can start the first request before the handshake completes. The benefits are largest on mobile networks where packet loss and high latency are normal: typical sites see 5 to 15 percent faster page loads when HTTP/3 is enabled, and very heavy single-page applications can see more.
This probe queries the URL once and reads the alt-svc response header. Modern servers and CDNs use that header to advertise the QUIC endpoint and version. If the header lists h3 or any h3-XX draft variant, the site supports HTTP/3 and the browser will switch to it on the next connection. The probe also detects server software via the server header (Cloudflare, Fastly, nginx-quic, LiteSpeed, h2o, Caddy, Vercel) and uses that to predict QUIC support when the alt-svc header is not present yet, for example because the response was the first contact and the server has not advertised it.
How the HTTP/3 probe works
- Normalise the input URL by adding
https://if missing and rejecting non-HTTPS targets (HTTP/3 only runs over TLS). - Run an HTTP request via the PeopleAreGeek
/wp-json/peoplearegeek/v1/headersendpoint. The first request uses HTTP/2 over TCP, which is enough to read thealt-svcdirective that announces QUIC. - Parse
alt-svcinto individual alternative-service tokens, extract the protocol identifiers (h3,h3-29,h2…), the optional port, and anyma(max-age) cache duration. - Inspect
serverand other clue headers (x-cdn,cf-ray,x-served-by,via) to recognise the server software and infer whether HTTP/3 is plausible even when not yet advertised. - Render the verdict: supported (alt-svc lists h3), likely (server software supports h3 but no alt-svc seen yet), unknown (insufficient data) or unsupported (no signal at all on a server known to be HTTP/3-incapable).
Common use cases for an HTTP/3 checker
- Mobile performance optimisation. Test your homepage and the slowest pages. HTTP/3 buys the most on cellular and unstable networks; if your traffic skews mobile, the migration is high impact.
- CDN migration planning. Before switching to a CDN that boasts HTTP/3 support, confirm the current setup does not already have it. Some origin servers (LiteSpeed, h2o, nginx-quic) ship HTTP/3 without a CDN.
- Vendor due diligence. A SaaS partner serving heavy assets over HTTP/1.1 in 2026 is a red flag. Run the probe and use the result in technical scorecards.
- SEO and Core Web Vitals. Faster TLS handshake and lower head-of-line blocking improve LCP and INP on mobile, which feeds into the search-ranking signal.
- Network troubleshooting. When users on certain ISPs report slow loads, confirming HTTP/3 is enabled removes one variable from the diagnosis.
- Browser/client compatibility audit. Confirm that older clients are still served correctly when HTTP/3 is enabled: HTTP/2 must remain the fallback for browsers that do not yet support QUIC.
Limitations and accuracy notes
The probe relies on the alt-svc response header. Some servers advertise HTTP/3 only after a few requests have been processed; the first response can therefore not contain the directive even though the server supports it. In that case the probe falls back to a server-software heuristic: Cloudflare, Fastly, LiteSpeed, nginx-quic, h2o and Caddy are known to enable HTTP/3 by default, so when those server strings are returned without alt-svc, the probe reports “likely supported” rather than “unsupported”. A definitive answer requires a real HTTP/3 client probe, which is outside what this server-side check can do directly.
The request is issued by the PeopleAreGeek server, not by your browser. Your IP is not exposed to the inspected origin. The URL is not stored after the probe completes. The probe makes one HTTPS request and reads a handful of response headers, which is the lowest-impact way to ask the question and is the same method used by major CDN dashboards to display HTTP/3 status.
Frequently asked questions
What does h3-29 mean in alt-svc?
Older draft versions of HTTP/3 used names like h3-29 (draft 29). The final RFC version is h3 with no suffix. Many servers still advertise both for compatibility with older clients. Seeing any h3* token means HTTP/3 is on.
Why is HTTP/3 reported as “likely” without explicit alt-svc?
Some servers only advertise the directive after the first response or after a session resumption. When the server software is Cloudflare, Fastly, LiteSpeed, h2o, nginx-quic or Caddy, HTTP/3 is on by default. The probe reports “likely” rather than “yes” because a strict yes requires a live HTTP/3 handshake.
Does enabling HTTP/3 require a new TLS certificate?
No. HTTP/3 uses the same TLS 1.3 layer that HTTP/2 over TCP uses. Your existing certificate works without changes. The server needs UDP port 443 open and a QUIC-capable build, which is the default in Cloudflare, Fastly, LiteSpeed, h2o and recent nginx-quic.
Is HTTP/3 always faster than HTTP/2?
On clean wired connections the difference is small. On mobile networks with packet loss, HTTP/3 is meaningfully faster (5-15 percent on typical sites, more on heavy single-page apps). A few corporate firewalls block UDP, in which case browsers fall back to HTTP/2.
Does Google care about HTTP/3 for SEO?
Indirectly. HTTP/3 improves Core Web Vitals on mobile, which feeds into the ranking signal. Google does not give a direct bonus for HTTP/3 itself, but a faster site is a better-ranking site, especially for mobile-first indexing.
How do I roll out HTTP/3 on my origin?
The fastest path is to put a CDN that supports HTTP/3 in front (Cloudflare, Fastly, CloudFront all support it as a toggle). For self-hosted setups, use LiteSpeed, h2o, Caddy or recent nginx-quic builds and open UDP port 443 in the firewall. The Recommendations tab on this page lists the exact steps.
