HTTP/3 and QUIC Checker

What HTTP/3 and QUIC change for a public site

HTTP/3 is the newest one in the family, and the real change is buried underneath. HTTP/1.1 and HTTP/2 both sit on TCP. HTTP/3 throws TCP out and rides on QUIC instead, a UDP-based transport that landed as RFC 9000 back in 2021. So what do you actually get out of it? Start with the big one: QUIC kills the head-of-line blocking that drags HTTP/2 down the second a network starts dropping packets. It also folds the crypto and transport handshakes into a single round trip, so connections come up faster. Then there's 0-RTT resumption, which lets a returning visitor fire off that first request before the handshake's even done. Where it earns its keep is mobile. Flaky signal, packets going missing, latency bouncing around. Typical sites pick up something like 5 to 15 percent on load times, and a heavy single-page app can do better than that.

The mechanism's simple enough. The probe hits your URL once and reads the alt-svc header off the response. That's the header modern servers and CDNs use to announce their QUIC endpoint and version. Spot h3 in there, or any h3-XX draft, and you're set: the browser hops over to HTTP/3 on its next connection. When the header's missing, the probe doesn't just shrug and give up. It reads the server header too (Cloudflare, Fastly, nginx-quic, LiteSpeed, h2o, Caddy, Vercel) and makes an educated guess, because honestly a lot of those won't bother advertising QUIC on a cold first contact even though it's wired up and waiting.

How the HTTP/3 probe works

1. Normalise the input URL. I tack on https:// if you forgot it, and I bounce anything that isn't HTTPS. HTTP/3 just won't run without TLS, full stop.
2. Run an HTTP request through our own headers endpoint. That first call goes out over HTTP/2 on TCP. Which is plenty. It's all I need to read the alt-svc line where QUIC gets announced.
3. Parse alt-svc by splitting it into its alternative-service tokens, then pulling out the protocol names (h3, h3-29, h2...), the optional port, and whatever ma (max-age) the server set for caching.
4. Inspect server and the other clue headers (x-cdn, cf-ray, x-served-by, via) to work out what's running, and whether HTTP/3 is a fair bet even when nothing's been advertised yet.
5. Render the verdict. Supported when alt-svc actually lists h3. Likely when the software does h3 but no alt-svc has shown up yet. Unknown when there's just too little to go on. Unsupported when there's no signal at all and the server is one I know can't do HTTP/3.

Common use cases for an HTTP/3 checker

• Mobile performance optimisation. Point it at your homepage, then at your worst pages. HTTP/3 earns its keep on cellular and shaky links, so if your audience lives on phones, flipping it on is probably one of the better returns you'll get for the effort.
• CDN migration planning. Tempted to move to a CDN because it brags about HTTP/3? Check first. You might already have it. Origin servers like LiteSpeed, h2o and nginx-quic do HTTP/3 on their own, no CDN in the picture.
• Vendor due diligence. A SaaS partner still shoving heavy assets at you over HTTP/1.1 in 2026? That tells you something. Run the probe, drop the result straight into your technical scorecard.
• SEO and Core Web Vitals. A quicker TLS handshake plus less head-of-line blocking nudges LCP and INP the right way on mobile, and those feed the ranking signal.
• Network troubleshooting. When people on one specific ISP keep saying the site feels slow, confirming HTTP/3 is on lets you cross one suspect off the list.
• Browser and client compatibility audit. Don't leave the old clients stranded. Turn HTTP/3 on, fine, but HTTP/2 has to stay put as the fallback for any browser that can't speak QUIC yet.

Limitations and accuracy notes

Straight talk about what this can and can't tell you, since the whole thing hangs on that one alt-svc header. Some servers won't show it until they've handled a few requests, so a first response can come back bare even though HTTP/3 is fully live. When that happens I fall back to reading the server software. Cloudflare, Fastly, LiteSpeed, nginx-quic, h2o and Caddy all default to HTTP/3, so seeing one of those names with no alt-svc gets you "likely supported" rather than a flat "no". For a rock-solid yes you'd need a real HTTP/3 client to open an actual handshake, and that's just not something a server-side check can pull off from here.

One more thing, and it matters: the request leaves our server, not your browser. The origin you're poking never sees your IP, and I don't hang onto the URL once the probe's done. It's a single HTTPS request reading a handful of headers. Same trick the big CDN dashboards use to show you HTTP/3 status, just with the curtain pulled back.

Frequently asked questions

What does h3-29 mean in alt-svc?

It's a leftover from before the spec got finalised. The drafts picked up names like h3-29 (yep, draft 29), while the finished RFC is just plain h3, no suffix. Loads of servers still advertise both so older clients don't get stranded. Spot any h3 token at all and HTTP/3 is on.

Why is HTTP/3 reported as "likely" without explicit alt-svc?

Because some servers sit on the directive until after the first response, or until a session gets resumed. So when I recognise the software as Cloudflare, Fastly, LiteSpeed, h2o, nginx-quic or Caddy, all of which ship HTTP/3 on by default, I will say "likely" instead of promising you a "yes". A real "yes" means opening a live HTTP/3 handshake. Not doing that here.

Does enabling HTTP/3 require a new TLS certificate?

Nope. Your cert's fine exactly as it is. HTTP/3 leans on the same TLS 1.3 layer that HTTP/2-over-TCP already uses, so there's nothing to reissue. What the server does need is UDP port 443 open plus a QUIC-capable build, and that build comes as the default on Cloudflare, Fastly, LiteSpeed, h2o and recent nginx-quic.

Is HTTP/3 always faster than HTTP/2?

Not always, no. On a clean wired link the gap is tiny, you'd be hard pressed to feel it. Honestly, I think people oversell HTTP/3 on desktop fibre, though I could be wrong for some workloads. On mobile, the moment packets start dropping, it pulls ahead for real: 5 to 15 percent on a typical site, more on a heavy single-page app. One gotcha. Some corporate firewalls block UDP outright, and when that happens the browser just quietly slips back to HTTP/2.

Does Google care about HTTP/3 for SEO?

Only sideways. There's no checkbox where Google hands you points for running HTTP/3, not directly. But it lifts your Core Web Vitals on mobile, and those do feed the ranking signal. So a faster site quietly ranks a bit better, and under mobile-first indexing that's worth more than it used to be.

How do I roll out HTTP/3 on my origin?

Quickest route by a mile: stick a CDN in front that already does it. Cloudflare, Fastly and CloudFront all expose HTTP/3 as a toggle. Want to keep it self-hosted instead? Run LiteSpeed, h2o, Caddy or a recent nginx-quic build, then open UDP port 443 in the firewall. That last bit is the one everyone forgets. The "How to enable HTTP/3" tab up top walks you through the exact steps for your stack.