How to Test Whether a Website Supports HTTP/3

To test whether a website supports HTTP/3, run curl --http3-only -I https://example.com/ with a curl build that supports HTTP/3. A successful response confirms that this client reached the site over HTTP/3. The --http3-only option does not silently fall back to HTTP/2 or HTTP/1.1. For a browser check, enable the Protocol column in DevTools’ Network panel and look for h3. An Alt-Svc header advertising h3 is a useful clue, but it is not proof of a successful HTTP/3 connection.

HTTP/3 runs over QUIC on UDP and uses the ALPN identifier h3. A site can support it while one client, browser, or network cannot reach it. This guide shows how to distinguish server advertisement from an actual negotiated connection, and how to interpret failures.

1. Run the strict HTTP/3 test with curl

First, check the exact HTTPS URL you care about. Substitute the site’s hostname and path:

curl --http3-only -I https://example.com/

The -I option asks for response headers. A successful HTTP response from this command demonstrates that the curl client connected using HTTP/3. The strict option matters: a successful transfer with a fallback-enabled command alone does not establish which HTTP version carried the request.

For example, test a specific page rather than only the root if it redirects or behaves differently:

curl --http3-only -I https://example.com/products/widget

Use HTTPS. HTTP/3’s standard procedure applies to HTTPS origins; entering a plain http:// URL is not the equivalent test.

Check whether your curl supports HTTP/3

If curl reports that --http3-only is unknown or unsupported, that says something about the local curl binary, not the website. HTTP/3 support depends on how curl and its TLS/QUIC libraries were built. Install or build a curl version with HTTP/3 support, then repeat the strict probe. The curl documentation describes --http3-only as the mode that uses only HTTP/3.

Keep the strict command for a yes-or-no negotiation check. If it fails, record the full error and test from another network or an external checker before concluding the origin does not support HTTP/3.

2. Understand the fallback command

You may also see this command:

curl --http3 -I https://example.com/

This allows HTTP/3 with fallback to HTTP/2 or HTTP/1.1. It can be useful as a tolerant connectivity check, but a successful response by itself does not prove HTTP/3 was used. Use --http3-only for strict verification, or inspect a reliable protocol/version indicator for the completed transfer.

Method	What it establishes	What it does not establish
curl --http3-only	Whether this client completed a request using HTTP/3	Whether every user, network, or hostname can do so
curl --http3	Whether a request completed with HTTP/3 allowed	HTTP/3 specifically, because fallback may have occurred
Alt-Svc: h3=...	The origin advertises an alternative HTTP/3 service	That the advertised QUIC endpoint is reachable and works
Browser Protocol column showing h3	That particular browser request used HTTP/3	That all resources or visits use HTTP/3

3. Verify HTTP/3 in browser DevTools

1. Open the site in Chrome or Chromium.
2. Open Developer Tools and select the Network panel.
3. Show the Protocol column. If it is not visible, use the Network table’s column configuration to enable it.
4. Reload the page and inspect the protocol value on the requests. Look for h3.
5. Reload again if the first visit used h2, and inspect the main document and any relevant asset hosts separately.

Browser discovery is opportunistic. The first HTTPS request may travel over HTTP/2 while the browser learns an HTTP/3 alternative from an Alt-Svc response. Later requests can then try QUIC. A first load showing h2 is therefore not conclusive evidence that the site lacks HTTP/3.

Also, a page is made up of requests to potentially different hostnames: the document, scripts, images, fonts, and API calls may use different origins or CDN edges. One asset showing h3 does not prove the main document host uses it, and one host’s result does not describe every third-party host. Inspect the exact request that matters to your question.

4. Read the Alt-Svc header correctly

Ask for response headers and look for a value like:

Alt-Svc: h3=":443"; ma=86400

The h3 token identifies an advertised HTTP/3 alternative; :443 indicates its port, and ma gives the advertisement’s lifetime in seconds. The IETF’s RFC 9114 says an HTTP origin can advertise an equivalent HTTP/3 endpoint through the Alt-Svc response header.

Treat this as a discovery hint, not a successful connection test. The browser or client still has to reach that endpoint over QUIC, validate TLS, and negotiate HTTP/3. If the endpoint is blocked, unavailable, or misconfigured, the advertisement can be present while an actual HTTP/3 request fails. Confirm with strict curl or a browser request whose Protocol value is h3.

5. Cross-check from another network

If strict curl fails locally but you suspect the website supports HTTP/3, use an online HTTP/3 checker such as HTTP3Verify to test negotiation from outside your network. An external result helps separate an origin-side issue from a local firewall, proxy, VPN, or ISP policy. Compare the exact hostname and, where possible, the response headers and negotiated ALPN information.

External and local tests answer different questions: the checker reports what its own network can negotiate, while your local test reports what your user or deployment environment can reach. For an operational issue, compare at least one strict local probe and one independent vantage point rather than assuming either represents every client.

6. Troubleshoot common results

Result	Likely cause	Next step
curl: option --http3-only is unknown	Your curl build lacks HTTP/3 support.	Install or build an HTTP/3-capable curl, then rerun the strict command.
--http3 succeeds, strict mode fails	The tolerant command may have fallen back, or QUIC is unreachable.	Use the strict result as the negotiation evidence; test UDP reachability and from another network.
Alt-Svc advertises h3, strict curl fails	The QUIC endpoint may be blocked, unreachable, misconfigured, rate-limited, or have a certificate problem.	Check the advertised service and certificate, then compare from an external probe and a different network.
Browser shows h2 on first visit	The browser may not have learned or tried the Alt-Svc mapping yet.	Reload after the discovery response; verify the target request’s Protocol value.
Browser continues to show h2	UDP/443 may be blocked, QUIC may be disabled, or a proxy/network policy may interfere.	Try a network without that restriction and use strict curl or an external probe for comparison.
Only some requests show h3	Requests may use different hostnames, redirects, CDNs, or third-party origins.	Test the exact URL and inspect each relevant host independently.
Plain HTTP URL does not negotiate HTTP/3	The test is not targeting an HTTPS origin.	Repeat against the site’s HTTPS URL.

Certificate validation errors deserve care: do not suppress TLS checks to turn a failed probe into a pass. A connection that cannot validate the advertised endpoint is not a successful, trustworthy HTTP/3 result for normal visitors.

7. Choose the test that matches your question

• “Can my server and network negotiate HTTP/3 with this host?” Use curl --http3-only.
• “Can this browser use HTTP/3 for this page?” Inspect the DevTools Protocol column after discovery and reload.
• “Does the origin advertise HTTP/3?” Inspect Alt-Svc, but do not treat that as proof of negotiation.
• “Is this failure only on my network?” Compare strict curl locally with an independent external probe.
• “Does the whole page use HTTP/3?” Inspect each host and request of interest; protocol selection can differ across origins and resources.

8. Performance, reliability, and test limits

HTTP/3’s use of QUIC over UDP and negotiation with ALPN h3 identify the protocol. A successful protocol test does not by itself show that a site is faster, more reliable, or better for every visitor. This procedure measures whether negotiation succeeded from a particular client and network; it is not a performance benchmark.

For a reproducible operational check, record the tested URL, time, client build, network, redirect behavior, and whether the result came from strict curl, DevTools, or an external checker. Repeat from the environments your users actually rely on. UDP/443 filtering, HTTP/3-disabled clients, proxies, certificate issues, and endpoint availability can all change the outcome without changing the site’s general capability.

Likewise, cache state and discovery affect browser behavior. A first request may use HTTP/2 and a later request HTTP/3 because the browser has learned an alternative. Do not compare a cold first visit with a warm subsequent visit as though they had identical discovery conditions.

9. Capture the page while investigating it

When a protocol issue is being debugged alongside a visual regression, a screenshot can preserve what the page looked like during the investigation. Screenshots do not reveal the negotiated transport protocol; use curl or DevTools for that evidence. They can, however, document a blank page, a consent overlay, or the rendered state associated with a test run.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. One GET request returns a PNG, JPEG, WebP, or PDF. Its screenshot captures can accept cookie/consent banners and remove 60+ known consent platforms, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, with response headers identifying the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000.

Use a screenshot as a visual record, not as an HTTP/3 negotiation test. See the ScreenshotNeo API documentation for request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Sign up for 1,000 free screenshots a month with no card.

10. Frequently asked questions

What does the h3 in ALPN mean?

It is the ALPN identifier HTTP/3 uses during protocol negotiation. Seeing it in negotiated connection details is evidence of HTTP/3; seeing it in an Alt-Svc advertisement is only evidence that an alternative was announced.

Can one site use HTTP/2 and HTTP/3 at the same time?

Yes. Different clients, visits, networks, hostnames, or requests can use different protocols. Test the particular connection or resource you need to diagnose.

Does a successful screenshot prove HTTP/3?

No. A screenshot records rendered page output. Use strict curl or the browser’s negotiated Protocol value to verify HTTP/3.

Why might a public checker disagree with my laptop?

The checker and laptop use different clients and network paths. UDP policy, proxies, QUIC availability, discovery state, and the specific endpoint can differ. Compare the same HTTPS hostname from both vantage points.