// detect http/2 and http/3 support in one click
Check if any website supports HTTP/2 or HTTP/3. Instant protocol detection with TLS version, ALPN negotiation, and server header info.
Enter any domain or full URL — HTTPS and HTTP supported
Ready to check
Enter a URL and click Check HTTP/2Type or paste any domain (e.g. example.com) or full URL. HTTPS and HTTP both work.
Our server connects to the target and negotiates the highest available protocol.
See protocol version, TLS details, server software, and Alt-Svc header for HTTP/3 hints.
HTTP/2 is the second major revision of the HTTP protocol. It introduces multiplexing, header compression (HPACK), and server push — dramatically improving page load performance over HTTP/1.1. HTTP/3 goes further by replacing TCP with QUIC for lower latency.
HTTP/2 is a major protocol upgrade over HTTP/1.1. It supports multiplexing (multiple requests over one connection), header compression, and binary framing — reducing page load times by 20–50% in typical scenarios. Enabling HTTP/2 on your server is one of the most impactful zero-effort performance wins available.
In practice, yes — all major browsers only support HTTP/2 over TLS (HTTPS). The HTTP/2 spec technically allows cleartext (h2c), but no mainstream browser implements it. This tool checks both, but you should always pair HTTP/2 with HTTPS in production.
ALPN (Application-Layer Protocol Negotiation) is a TLS extension that allows the client and server to agree on an application protocol (like h2 for HTTP/2) during the TLS handshake. If the server advertises "h2" in its ALPN list, HTTP/2 is supported. This tool reads the negotiated ALPN result directly.
HTTP/3 replaces TCP with QUIC — a UDP-based transport developed by Google. QUIC eliminates head-of-line blocking at the transport layer and improves connection establishment speed (0-RTT handshakes). HTTP/3 support is often advertised via the Alt-Svc response header. This tool detects that header and flags HTTP/3 readiness.
Common causes include: a reverse proxy (like a load balancer) in front of your server that terminates HTTP/2 and uses HTTP/1.1 upstream; a CDN that doesn't pass the protocol to the origin; missing ALPN configuration in your server's TLS setup; or checking an HTTP (not HTTPS) URL. Check your Nginx/Apache config for listen 443 http2; or equivalent.
HTTP/2 requires TLS 1.2 at minimum, but TLS 1.3 is strongly recommended. TLS 1.3 reduces handshake round-trips from 2 to 1 (or 0 for resumptions), significantly boosting the performance benefits of HTTP/2. TLS 1.0 and 1.1 are deprecated and not permitted with HTTP/2.
No — this tool makes requests from our server to a publicly reachable hostname. For localhost or internal IPs, you can use browser DevTools (Network tab → Protocol column shows "h2" for HTTP/2), or tools like curl --http2 -I https://localhost from your own machine.
Yes, completely free with no sign-up required. The check runs server-side to accurately negotiate the TLS+ALPN handshake. We apply basic rate limiting to prevent abuse, but normal usage is unrestricted. No data is stored or logged beyond what's needed to serve the response.
Our HTTP/2 Checker lets you instantly verify whether any website supports the HTTP/2 or HTTP/3 protocol. Simply enter a domain name or full URL and our tool connects to the server, negotiates the TLS handshake, and reports exactly which HTTP version was agreed upon — along with TLS version, cipher suite, ALPN details, and server software.
HTTP/1.1 was designed in 1997 when web pages consisted of a handful of resources. Today's web applications routinely load dozens to hundreds of assets — scripts, stylesheets, fonts, images, API calls. HTTP/1.1 handles these serially (or with limited parallelism via multiple TCP connections), creating a queue that slows page rendering.
HTTP/2 solves this with multiplexing: multiple requests and responses can be in-flight simultaneously over a single TCP connection. There's no head-of-line blocking at the application layer, meaning a slow response to one request doesn't delay all others. Combined with header compression via HPACK (which dramatically reduces the overhead of repeated headers like cookies) and server push (proactively sending resources the browser will need), HTTP/2 can reduce page load times by 20–50% compared to HTTP/1.1.
HTTP/2 over TLS is negotiated using ALPN (Application-Layer Protocol Negotiation), a TLS extension standardized in RFC 7301. During the TLS ClientHello, the client sends a list of supported protocols (e.g. h2, http/1.1). The server selects the highest protocol it supports from that list and includes its choice in the ServerHello. If both sides support h2, HTTP/2 is used for the connection.
This means HTTP/2 support is actually a TLS-layer decision, not an HTTP-layer one. A server can be running Apache or Nginx with HTTP/2 enabled, but if the TLS terminator in front of it (a load balancer, CDN edge node, or reverse proxy) doesn't advertise h2 in ALPN, the connection will fall back to HTTP/1.1. This is a common gotcha in cloud deployments.
When you run a check, our tool reports:
HTTP/2, HTTP/3, or HTTP/1.1. This is the ground truth from the TLS negotiation, not a guess based on server type.Alt-Svc response header, which servers use to advertise HTTP/3 support. A value like h3=":443"; ma=86400 means the server is ready for HTTP/3 connections on port 443.Server response header, revealing the web server software (nginx, Apache, Cloudflare, LiteSpeed, etc.).HTTP/3 is the third major version of the protocol, standardized in RFC 9114. Unlike HTTP/1.1 and HTTP/2 which run over TCP, HTTP/3 is built on QUIC — a transport protocol using UDP. QUIC was designed by Google to address the fundamental limitation of TCP: head-of-line blocking at the transport layer. In HTTP/2, if a single TCP packet is lost, all streams stall until the packet is retransmitted. QUIC solves this by making each stream independent at the transport level.
HTTP/3 also achieves faster connection establishment. A fresh TLS 1.3 + QUIC handshake takes just 1 RTT (round trip), and with 0-RTT resumption for returning clients, it can be effectively instant. This is especially impactful on mobile networks where latency is high and packet loss is common.
Since browsers can't know in advance whether a server supports HTTP/3, servers advertise it via the Alt-Svc HTTP response header. Subsequent visits use HTTP/3. Our checker reads this header and flags it when present.
On Nginx, add http2 to your listen directive: listen 443 ssl http2;. Ensure you're running Nginx 1.9.5+ and have a valid SSL certificate configured.
On Apache, enable the mod_http2 module (a2enmod http2 on Debian/Ubuntu) and add Protocols h2 http/1.1 to your VirtualHost. Requires Apache 2.4.17+ and MPM event or worker (not prefork).
On Caddy, HTTP/2 and HTTP/3 are enabled automatically with no configuration needed — it's one of the main advantages of using Caddy as a web server.
For CDN deployments (Cloudflare, Fastly, AWS CloudFront), HTTP/2 is typically enabled in the CDN dashboard settings. The origin server doesn't need to support HTTP/2 — the CDN terminates HTTP/2 from clients and may use HTTP/1.1 to the origin.
If our checker reports HTTP/1.1 for a server you believe has HTTP/2 enabled, check these common causes: the SSL certificate may be misconfigured (HTTP/2 requires a working TLS setup); a load balancer or CDN in front of your server may not be forwarding HTTP/2; the server may be running an older version that predates HTTP/2 support; or the server's ALPN configuration may be missing the h2 protocol token.
You can also verify locally with curl: curl -I --http2 https://yoursite.com — look for HTTP/2 200 in the response. The --http2-prior-knowledge flag forces HTTP/2 without ALPN negotiation, useful for testing cleartext h2c servers.