HTTP/2 Test — Verify HTTP/2 and ALPN Support

Returns the HTTP protocol version negotiated by the server — HTTP/2 or HTTP/1.1 — plus full response headers for any domain or hostname.

More Tools

HTTP/2 Test — Check Your Web Server's Protocol Version

HTTP/2 test verifies whether a web server supports the HTTP/2 protocol (RFC 9113) by checking Application-Layer Protocol Negotiation (ALPN, RFC 7301) during a TLS handshake on port 443. The server announces its supported protocols in the TLS ClientHello — if h2 is present, HTTP/2 is active for that connection. Results include the negotiated protocol version and the full set of HTTP response headers returned by the server.

Property	Value
Protocol standard	RFC 9113 (supersedes RFC 7540, 2022)
Originally standardized	2015 by the IETF
Negotiation mechanism	ALPN — Application-Layer Protocol Negotiation (RFC 7301)
Transport layer	TCP — HTTPS port 443
Browser requirement	HTTPS required — all major browsers enforce h2 over TLS only
Global adoption (2025)	~77% of websites (W3Techs)

How to Test HTTP/2 Support

Enter a domain name to test whether its web server negotiates HTTP/2 during the TLS handshake on port 443.

Enter the Domain Name

Type the domain name to test — for example, google.com. Do not include https://, a subdirectory path, or query parameters.

Run the HTTP/2 Test

Click "Test HTTP/2 Support". The tool connects to port 443 over HTTPS and checks whether the server advertises h2 in its ALPN extension during the TLS handshake.

Interpret the Protocol Result

SUPPORTED means the server advertised h2 via ALPN and HTTP/2 is active. NOT SUPPORTED means the server uses HTTP/1.1 only, or HTTPS is not configured on port 443.

HTTP/1.1 vs HTTP/2 vs HTTP/3 — Protocol Comparison

HTTP/2 is the second of three major HTTP versions currently in active use. The table below covers the technical differences across all three — the features HTTP/2 added over HTTP/1.1, and what HTTP/3 improves further.

Feature	HTTP/1.1 (RFC 9112)	HTTP/2 (RFC 9113)	HTTP/3 (RFC 9114)
Year standardized	1997	2015	2022
Transport	TCP	TCP	QUIC over UDP (RFC 9000)
Multiplexing	No — one request per connection	Yes — concurrent streams over one TCP connection	Yes — independent streams over QUIC
Header compression	None	HPACK	QPACK
Head-of-line blocking	Yes — TCP and HTTP level	Partial — TCP-level blocking remains	Eliminated — QUIC streams are independent
Encryption	Optional	Effectively required (browsers enforce HTTPS)	Required — TLS 1.3 embedded in QUIC
Protocol negotiation	Upgrade header (rarely used)	ALPN extension in TLS handshake (RFC 7301)	Alt-Svc header from HTTP/2 response
Framing format	Text-based	Binary frames	Binary frames over QUIC

How HTTP/2 Negotiation Works via ALPN (RFC 7301)

HTTP/2 support is detected via Application-Layer Protocol Negotiation (ALPN), a TLS extension defined in RFC 7301. ALPN allows the client and server to agree on an application protocol during the TLS handshake — before any HTTP data is exchanged — with zero additional round trips.

TLS ClientHello — The client includes an ALPN extension listing supported protocols, typically ["h2", "http/1.1"], in priority order.
TLS ServerHello — The server selects a protocol from the client's list and returns it in the ALPN extension of its ServerHello. If it selects h2, HTTP/2 is active from the first request without any additional negotiation.
h2 vs h2c — h2 refers to HTTP/2 over TLS (ALPN-negotiated). h2c refers to HTTP/2 over unencrypted TCP. All major browsers reject h2c — encrypted HTTP/2 via ALPN is the only practical deployment.
HTTP/3 advertisement — Once connected via HTTP/2, servers that also support HTTP/3 advertise it via the Alt-Svc: h3=":443" response header. Browsers cache this and upgrade to HTTP/3 (QUIC, RFC 9000) on subsequent visits.

Do it yourself

How to Enable HTTP/2 on Your Web Server

HTTP/2 requires a valid TLS certificate and server software configured to advertise h2 in the ALPN extension. The configuration required differs by server software.

Server Nginx

server {
    listen 443 ssl http2;
    ssl_certificate     /etc/ssl/certs/your-domain.crt;
    ssl_certificate_key /etc/ssl/private/your-domain.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
}

Server Apache (requires mod_http2)

LoadModule http2_module modules/mod_http2.so

<VirtualHost *:443>
    Protocols h2 h2c http/1.1
    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/your-domain.crt
    SSLCertificateKeyFile /etc/ssl/private/your-domain.key
</VirtualHost>

Server Caddy

your-domain.com {
    # HTTP/2 is enabled by default — no directive required
}

Cloud CDN and Cloud Platforms

Cloudflare, AWS CloudFront, Fastly, Bunny.net, Netlify, and Vercel enable HTTP/2 automatically for all proxied domains. No server configuration is required. Confirm status in the provider dashboard under TLS or Performance settings.

Do it yourself

How to Test HTTP/2 Without an Online Tool

HTTP/2 support can be verified from any terminal. curl ships with Windows 10+, macOS, and all Linux distributions. openssl provides direct ALPN inspection without making an HTTP request.

Windows Command Prompt or PowerShell

curl.exe -I --http2 https://google.com -w "\nHTTP version: %{http_version}\n"

Mac / Linux curl

curl -I --http2 https://google.com -w "\nHTTP version: %{http_version}\n"

A response status line of HTTP/2 200 confirms HTTP/2 support. A HTTP/1.1 200 response confirms the server uses HTTP/1.1 only.

Inspect ALPN Negotiation Directly — OpenSSL

openssl s_client -connect google.com:443 -alpn h2 2>/dev/null | grep "ALPN"

Output of ALPN protocol: h2 confirms the server accepted the HTTP/2 ALPN token. Output of No ALPN negotiated or ALPN protocol: http/1.1 means HTTP/2 is not supported.

The online tool tests from a neutral external server — results may differ from your local terminal if a CDN, WAF, or load balancer intercepts TLS before it reaches the origin server.

Common Uses for HTTP/2 Testing

A web performance engineer migrating a high-traffic e-commerce site from Apache to Nginx runs an HTTP/2 test post-migration and receives NOT SUPPORTED. The Nginx configuration has TLS enabled but is missing the http2 flag on the listen directive. Adding listen 443 ssl http2; and reloading Nginx resolves the test immediately, restoring the multiplexed connection behaviour that was active on the previous CDN layer.

A DevOps engineer deploying a new API behind an AWS Application Load Balancer checks HTTP/2 support and finds the ALB is returning HTTP/1.1 to external clients. The root cause is that the ALB listener protocol is set to HTTP/1.1 for the backend target group. Switching the target group protocol version to HTTP/2 in the ALB configuration restores end-to-end HTTP/2 negotiation between client and origin.

An SEO consultant verifying Core Web Vitals improvements for a client discovers the apex domain (without www) returns NOT SUPPORTED while the www subdomain returns SUPPORTED. The split is caused by different CNAME routing paths through the CDN — the apex domain's A record routes directly to the origin server with no CDN proxy, where HTTP/2 was not configured at the Nginx level.

Frequently Asked Questions

What is HTTP/2 and why does it matter for website performance?

HTTP/2 (RFC 9113) is the second major revision of the HTTP protocol, standardized in 2015 and updated in 2022. It replaces HTTP/1.1's one-request-per-connection model with multiplexed streams — multiple requests and responses flow concurrently over a single TCP connection — eliminating the serial bottleneck that forces browsers to open multiple connections. It also adds HPACK header compression and binary framing, which reduce per-request overhead. Most browsers enforce HTTP/2 exclusively over HTTPS; an unencrypted HTTP/2 path (h2c) exists in the spec but is rejected by all major browsers.

Why does the test show NOT SUPPORTED when my hosting provider says HTTP/2 is enabled?

HTTP/2 requires a valid TLS certificate and the server or load balancer must advertise h2 in its ALPN configuration. Common causes of a NOT SUPPORTED result despite claimed support: the web server binary supports HTTP/2 but the listen directive is missing the http2 flag (Nginx), mod_http2 is installed but not loaded in Apache, a CDN or load balancer in front terminates TLS without forwarding ALPN negotiation to the origin, or a firewall strips TLS before it reaches the server. Run curl --http2 -I https://yourdomain.com from the server itself to isolate whether the issue is at the origin or the edge.

How is HTTP/2 negotiated between a client and a server?

HTTP/2 uses Application-Layer Protocol Negotiation (ALPN, RFC 7301), a TLS extension embedded in the ClientHello message during the TLS handshake. The client includes a list of supported application protocols — typically ["h2", "http/1.1"]. The server selects h2 if it supports HTTP/2 and returns that choice in the ServerHello ALPN extension. If neither side advertises h2, the connection falls back to HTTP/1.1. Because ALPN is part of the TLS handshake, HTTP/2 negotiation completes before any HTTP data is exchanged and without any extra round trips.

What is the difference between HTTP/2 and HTTP/3?

HTTP/2 (RFC 9113) runs over TCP and negotiates via ALPN during a TLS handshake. HTTP/3 (RFC 9114) runs over QUIC (RFC 9000), which uses UDP instead of TCP, eliminating TCP-level head-of-line blocking that still affects HTTP/2 streams when a TCP packet is lost. HTTP/3 uses QPACK for header compression instead of HPACK. Servers advertise HTTP/3 support via an Alt-Svc response header (e.g., Alt-Svc: h3=":443") returned inside an HTTP/2 response. As of 2025, approximately 77% of websites use HTTP/2 and approximately 30% use HTTP/3 (W3Techs).

How do I enable HTTP/2 on my web server?

HTTP/2 requires a valid TLS certificate and server software configured to advertise h2 in ALPN. For Nginx: add http2 to the listen directive — listen 443 ssl http2. For Apache: load mod_http2 and add Protocols h2 h2c http/1.1 to the VirtualHost block. Caddy enables HTTP/2 by default with no configuration required. CDN providers including Cloudflare, AWS CloudFront, Fastly, and Bunny.net enable HTTP/2 automatically — no server configuration is required when traffic is proxied through these services.

Do you store or log the domains I test?

No. HTTP/2 test requests are executed server-side in real time. No domain names, IP addresses, test results, or timestamps are stored or logged. Results reflect the server's live configuration at the exact moment of the request.

Related Guides

Guide What Is a VPN?

VPN tunnels terminate TLS between client and VPN server; understanding how VPN encryption interacts with HTTP/2 ALPN negotiation clarifies why protocol results may differ on a VPN connection.

Guide What Is a Proxy Server?

Forward and reverse proxies commonly terminate TLS. Any proxy between client and origin must be configured to pass h2 ALPN negotiation through to the backend — misconfigured proxies are a frequent cause of unexpected NOT SUPPORTED results.

HTTP/2 Support Test