Our Emerging Protocols Checker tests whether a server supports modern web protocols including HTTP/2 (h2), HTTP/3 (QUIC), and ALPN (Application-Layer Protocol Negotiation). These protocols offer significant performance improvements over HTTP/1.1, including multiplexing, reduced latency, and better connection management. Check any domain to see which emerging protocols are supported.
How to Use
1Enter the domain you want to test.
2Click "Check" to test protocol support.
3Review results for HTTP/2, HTTP/3, and ALPN support.
4Use the findings to plan server upgrades for better performance.
Use Cases
•Verify HTTP/2 and HTTP/3 support before enabling them
•Check ALPN negotiation for modern application protocols
•Audit CDN and reverse proxy protocol support
•Plan migration from HTTP/1.1 to HTTP/2 or HTTP/3
Frequently Asked Questions
Application-Layer Protocol Negotiation is a TLS extension that lets the client and server agree which protocol to run over the encrypted connection during the handshake. The client offers a list such as h2 and http/1.1, the server picks one, and everything after that uses that protocol. It is why a browser and a server can speak HTTP/2 without either being configured for the other, and it is negotiated inside the handshake, so it costs no extra round trip.
The third major version of HTTP, built on QUIC rather than TCP, which means it runs over UDP and negotiates transport security inside the same handshake. The practical consequences are a faster connection establishment for a new client, no head-of-line blocking between streams when a packet is lost, and connections that survive a network change such as moving between mobile and wifi. It also has a fallback: because UDP is blocked on some networks, a client that cannot reach it quietly drops back to HTTP/2.
Yes. Both HTTP/2 and HTTP/3 are specified to run over TLS, and browsers will not speak either in the clear. In practice that means no protocol negotiation happens on a plain HTTP connection at all, so a server that has not been converted to HTTPS reports neither, regardless of whether it could support them. The upgrade is the prerequisite rather than an optional extra: the protocol version you can negotiate is bounded by whether the connection is encrypted in the first place.
Mainly because it removes the serialisation penalty HTTP/1.1 imposed. A page needs dozens of subresources, and HTTP/1.1 limits a client to a handful of connections per origin, so requests queue behind each other; HTTP/2 multiplexes them over one connection and compresses the repeated headers that make up most of a small request. On modern TLS the performance difference is real but moderate, so the honest framing is that it costs little and helps most on high-latency mobile connections, where queueing hurts most.
It advertises an alternative endpoint for the same origin. A server returns it on an ordinary HTTPS response, naming a protocol and a port — Alt-Svc: h3=":443"; ma=2592000 — and the browser records it, trying that endpoint first on later visits and falling back silently if it fails. It is how HTTP/3 reaches browsers without anyone changing a URL. Because the decision is cached until ma expires, removing support later does not take effect immediately.
Because the interesting problems with HTTP/3 are transport problems, and fixing them at the HTTP layer would mean rewriting TCP's behaviour per connection. QUIC builds the reliability, ordering and congestion control into a stream-multiplexed protocol over UDP, and it can negotiate that inside the encrypted handshake rather than in a separate round of packets. The practical wins are a faster handshake, no head-of-line blocking between streams, and per-connection migration that survives a network change. The cost is that UDP is blocked or throttled on some networks, which is why fallback remains necessary.
No, and the honest answer is that it is faster on some networks and not on others. On a good connection the two are close, because HTTP/2 already removed the main cost that HTTP/3 was designed to address. On a lossy mobile or long-distance path HTTP/3 wins clearly, because a lost packet blocks only its own stream instead of everything behind it. On a network that throttles or drops UDP, it can be slower until the browser falls back. Treat it as an improvement for mobile users rather than a universal upgrade.
Because ALPN here runs inside a TLS handshake over TCP, and HTTP/3 is not carried over TCP at all. It runs over QUIC, which negotiates its own version identifiers during its own handshake on a UDP socket. Offering h3 in a TCP ALPN list would be meaningless. That is also why this page reports HTTP/3 support from the Alt-Svc header rather than from a negotiation: the advertisement is the signal that a client would act on when it next connects.
Put a QUIC-capable reverse proxy or CDN in front that will terminate HTTP/3 on UDP 443 and forward what it receives to your origin over HTTP/2 or HTTP/1.1, then confirm the Alt-Svc header appears in responses. Your origin does not need to speak QUIC at all, which is why this is usually a configuration change at the edge rather than a rebuild. Check that UDP 443 is reachable through your firewall, since a blocked port produces the same symptom as no support: browsers quietly stay on HTTP/2.
How the Check Works
HTTP/2 and HTTP/3 are negotiated differently, so confirming support takes two separate probes rather than one.
1A request is made over ordinary TLS and the protocol version of the response is read. If it came back as HTTP/2, HTTP/2 is in use on this connection.
2The Alt-Svc header is read from the same response. When it advertises an h3 endpoint, the server is prepared for HTTP/3 and is telling browsers to try it on a future visit.
3A separate handshake offers h2 and http/1.1 through ALPN, and the protocol the server selects is what it will actually serve over TCP.
HTTP/3 is not offered in the ALPN list on purpose. It runs over QUIC on UDP, not over TLS on TCP, so it is negotiated in a completely different handshake that this TCP-based probe cannot reach.
Tips & Best Practices
•Monitor emerging protocols for future TLS deployment planning
•Test emerging protocol support in development environments
•Evaluate emerging protocols for security and performance benefits
•Plan migration strategies for adopting new protocols
Technical Details
Protocols: TLS 1.3, QUIC, HTTP/3, ECH, and other emerging standards Status: Implementation status across major browsers and servers Security: Security analysis of emerging protocol features Output: Emerging protocol readiness assessment
