ALPN Protocol ID Reference
All registered ALPN protocol identifiers — h2, h3, http/1.1 and more.
Overview
The ALPN protocol ID reference lists every Application-Layer Protocol Negotiation identifier registered with IANA. ALPN is the TLS extension that lets a client and server agree on which protocol — HTTP/2, HTTP/3, gRPC, IMAP, or something more obscure — will ride on top of the encrypted channel before the first byte of application data flows.
This page is aimed at TLS implementers, load balancer operators, and curious engineers who need an ALPN identifier list for browsers or servers. Long-tail keywords covered: full ALPN protocol ID registry lookup, ALPN string for HTTP/2 vs HTTP/3, and which ALPN identifier to advertise for gRPC.
How it works
ALPN is defined in RFC 7301. The client sends a list of preferred protocol identifiers inside the TLS ClientHello; the server picks one and echoes it back in the ServerHello extension. Each identifier is an opaque byte string with no implied semantics — h2 simply means "HTTP/2 over TLS" by convention, and h3 means "HTTP/3 over QUIC". Because the negotiation happens during the handshake, there is no extra round trip, and the chosen protocol is bound to that connection.
IANA maintains the canonical registry. Some identifiers are case sensitive (h2 not H2), some carry a version suffix (stun.turn), and some are draft-only and should not be used in production.
Examples
h2— HTTP/2 over TLS, the value every modern web browser advertises.http/1.1— HTTP/1.1 over TLS, still required as a fallback by most clients.h3— HTTP/3, which actually runs over QUIC rather than TCP.acme-tls/1— used by certificate authorities to perform the TLS-ALPN-01 domain validation challenge.
FAQ
Why does HTTP/3 use h3 if it does not run over TLS directly?
QUIC embeds TLS 1.3 inside its own transport, and the same ALPN extension is reused during the QUIC handshake. The negotiation mechanism is identical even though there is no TCP underneath.
What happens if no ALPN values overlap?
The server returns a no_application_protocol alert (code 120) and the handshake fails. Clients should always include http/1.1 as a fallback when speaking to general-purpose web servers.
Is ALPN encrypted?
In TLS 1.2 the extension is sent in the clear. In TLS 1.3 with Encrypted ClientHello (ECH) the entire inner ClientHello, ALPN included, is hidden from on-path observers.
Can a custom protocol use any string?
Technically yes, but IANA recommends registering identifiers to avoid collisions. Private deployments often use a reverse-DNS-style prefix like com.example.proto1.