HTTP/2 & HTTP/3 Checker: Free Protocol Test

The HTTP/2 and HTTP/3 checker shows which web protocol a website actually uses when you connect to it. Enter a URL or bare domain and you get a clear result for HTTP/2, a separate result for HTTP/3 (QUIC), plus the server name, Alt-Svc header and final HTTP status code. It suits site owners, developers and SEO teams.

What Are HTTP/2 and HTTP/3?

HTTP/2 and HTTP/3 are newer versions of the protocol that browsers and servers use to exchange web pages, images, scripts and stylesheets. Each version changes how requests travel over the network, not what your pages look like. Your HTML, CSS and JavaScript stay the same.

The jump from HTTP/1.1 to HTTP/2 mainly fixed wasted connections. The jump from HTTP/2 to HTTP/3 fixed a delay that remained at the transport layer.

HTTP/1.1 versus HTTP/2

With HTTP/1.1, a browser opens several connections to the same host and loads files in small batches. HTTP/2 uses multiplexing, which lets many requests and responses travel together over a single connection. It also compresses request headers, so repeated data such as cookies costs fewer bytes. Browsers use HTTP/2 only over HTTPS.

HTTP/2 versus HTTP/3

HTTP/2 still sits on TCP, so one lost packet can hold up every stream on that connection. HTTP/3 moves to QUIC, which runs over UDP and treats each stream independently. QUIC also builds encryption into connection setup, which can shorten the wait before the first byte arrives. This matters most on mobile and unstable networks.

How to Use the HTTP/2 and HTTP/3 Checker

You can run a check in under a minute with one field and one button. Follow these steps:

1. Type or paste the address into the Website URL field. A full address such as https://example.com works, and so does a bare domain.
2. If you enter only a domain, the checker assumes HTTPS. Add http:// yourself only when you want to see how the unencrypted address behaves.
3. Click Check Protocol. The button changes to Checking... while the request runs.
4. Read the HTTP/2 and HTTP/3 (QUIC) rows first, then the TLS Version row.
5. Scan the extra lines below them: Server, Alt-Svc and HTTP Code. They explain why you got the result.
6. Repeat for other hostnames you own, such as the www and non-www versions or a separate subdomain for images.

Worked Example: Reading a Typical Result

Say you check shop.example.com, an online store behind a content delivery network. You enter the bare domain and click Check Protocol. The page returns something like this:

• HTTP/2: Negotiated
• HTTP/3 (QUIC): Advertised by Alt-Svc, not negotiated
• TLS Version: TLS version not measured
• Server: nginx
• Alt-Svc: h3=":443"; ma=86400
• HTTP Code: 200

Here is what that means. The connection used HTTP/2, so multiplexing and header compression are working. The Alt-Svc header tells browsers that the same site is available over HTTP/3 on port 443 and that the hint is valid for 86,400 seconds (one day). A visitor's browser can switch to HTTP/3 on a later visit.

The 200 code means the final page loaded normally after any redirects. Nothing needs fixing here. If HTTP/3 were not advertised and you wanted it, your next step would be a hosting or CDN setting, not a code change.

How to Read and Act on Your Results

Each row answers one question, and each outcome has a clear next step. Use this guide to decide what, if anything, to change.

HTTP/2 row

Negotiated is the result you want. It means the server agreed to HTTP/2 during this check. Not negotiated in this check means the connection fell back to an older version, usually HTTP/1.1. Ask your host to enable HTTP/2, or turn it on in your CDN or web server settings. HTTPS must already be working.

HTTP/3 (QUIC) row

There are three possible outcomes. Negotiated means HTTP/3 was used. Advertised by Alt-Svc, not negotiated means the server announces HTTP/3 support, which is how browsers normally discover it. Not observed means the check found no sign of HTTP/3. Most HTTP/3 sites show the advertised state, because browsers learn about HTTP/3 from the Alt-Svc header and connect over it on a later visit.

TLS Version row

This row does not report a real TLS version. For HTTPS addresses it reads "TLS version not measured", and for plain http:// addresses it reads "No TLS on requested URL". The second message is a flag: without HTTPS, browsers will not use HTTP/2 or HTTP/3 at all.

Server, Alt-Svc and HTTP Code

The Server line names the software or CDN that answered, when the site shares it. The Alt-Svc line shows the raw header, so you can confirm tokens such as h3. The HTTP Code is the final status after up to three redirects. A 301 or 302 chain that ends on a 404 or 500 means you should fix the destination page first. For a closer look at all response headers, use the HTTP header checker or the HTTP header analyzer.

HTTP/2 vs HTTP/3: Does It Matter for SEO?

The protocol is not a direct ranking signal, but it affects the speed visitors experience, and speed feeds into page experience. Google's Search Central documentation says Googlebot can crawl over HTTP/2 when a site supports it, which can reduce the load of crawling many resources.

If you must prioritize, get HTTP/2 working first. It is widely supported and often a single switch at your host. HTTP/3 is a useful extra, mostly for visitors on mobile or weak connections. Protocol upgrades will not fix heavy images, render-blocking scripts or slow server responses, so pair them with compression checks and normal page-speed work.

Who Should Use This Checker?

Anyone who needs a fast, plain answer about protocol support will get value from it. Typical situations include:

• Site owners confirming that a new hosting plan or CDN really delivers HTTP/2.
• Developers verifying that an Alt-Svc header is present after enabling HTTP/3 on a server or load balancer.
• SEO specialists adding protocol support to a technical audit of a client site.
• Migration teams comparing the old and new hostnames after a move. Pair this with the bulk HTTP status checker to verify redirects across many URLs.
• Learners who want to see how HTTP/1.1, HTTP/2 and HTTP/3 differ on real sites.

Best Practices and Troubleshooting Tips

Most surprising results come from checking the wrong address or misreading a redirect. These checks resolve nearly all of them.

• Test every hostname. The www, non-www, and subdomain versions can sit on different servers with different settings.
• Use https://. An http:// address with no redirect shows no TLS, and HTTP/2 will not be negotiated on it.
• Watch the redirect target. The check follows up to three redirects, so the result describes the final destination. A long redirect chain may end somewhere you did not expect.
• HTTP/2 missing on HTTPS? Check whether your host or CDN has the setting turned off, or whether an old proxy in front of your server is downgrading connections.
• HTTP/3 not observed? Enable it at the CDN or server, confirm UDP port 443 is open, and make sure the Alt-Svc header is sent.
• "Please enter a valid URL or domain" error? Remove spaces and stray characters, then retry with just the domain.
• "Not reachable as a public address" error? The tool checks public websites only, so local and internal addresses will not work.
• Connection error? The site may be down, blocking automated requests, or have a certificate problem. Open it in a browser to confirm.

Limits to Keep in Mind

This tool inspects the negotiated HTTP version and any HTTP/3 advertisement. It does not measure TLS versions, cipher suites or speed, so do not treat it as a performance test. It reads one response from one connection, and CDNs can behave differently by region or over time. Run it again if a result looks odd, and use browser developer tools when you need to see the protocol used for each individual file.

You now know how to confirm HTTP/2 support, spot an HTTP/3 advertisement and decide what to fix. Enter your URL in the field above, click Check Protocol, and then work through the headers and routes that need attention. The website audit and performance tools cover the next checks on your list.