What Is HTTP/3?

Modern web server sending several encrypted data streams to a browser

HTTP/3 Explainer

HTTP/3 is a version of the Hypertext Transfer Protocol that carries web requests and responses over QUIC instead of TCP. The familiar HTTP concepts remain: a client sends a method, target, fields, and optional content; the server returns a status, fields, and content. What changes is how those messages travel. QUIC supplies encryption, reliable delivery, congestion control, and many independent streams over UDP. HTTP/3 defines how to map each exchange onto those streams and how to coordinate settings, header compression, and connection-wide control information.

A browser usually discovers HTTP/3 support through prior knowledge or an advertisement from a server reached by another HTTP version. It then opens a QUIC connection and negotiates HTTP/3 as the application protocol during the TLS handshake built into QUIC. Client and server each create a control stream for settings and other connection-wide instructions. Additional unidirectional streams support header compression. Individual requests normally use bidirectional streams, so a request and its response share one ordered context without forcing unrelated exchanges into the same byte sequence.

That stream model addresses an important delay problem. HTTP/2 multiplexes many requests over one TCP connection, but TCP must deliver bytes in order across the entire connection. If one packet is missing, later bytes for every HTTP/2 stream can wait in the receiving TCP stack. QUIC keeps ordering within each stream. A lost packet can delay the stream that needs those bytes while complete bytes on other streams are delivered. The streams still share path congestion control, so HTTP/3 does not create unlimited independent traffic; it removes transport-level head-of-line blocking between requests.

HTTP/3 compresses fields with QPACK. Repeated names and values can be represented by compact references to shared tables, reducing overhead. Dynamic table updates create dependencies, however, and a missing instruction must not freeze every request. QPACK therefore separates encoder and decoder instructions onto dedicated streams and limits how many request streams may be blocked waiting for table entries. Implementations can favor static references or literal fields when lower dependency risk is more valuable than maximum compression.

QUIC connection identifiers also let an HTTP/3 connection survive some address changes, such as a mobile device switching networks. The endpoints validate a new path and preserve the secure connection when policy allows. Because QUIC encrypts most transport control information, middleboxes have fewer opportunities to rewrite protocol details, while endpoints can update their implementation without changing an operating-system TCP stack. Servers can send connection-close information, request cancellation uses stream mechanisms, and prioritized delivery remains an application decision rather than a guarantee that every resource arrives in a particular order.

Deployment still needs fallbacks. Some networks block or impair UDP, and an application may return to HTTP/2 or HTTP/1.1 over TCP. QUIC’s encryption and user-space implementation can alter monitoring, load balancing, and debugging practices. Servers must manage certificate validation, anti-amplification limits, connection state, CPU cost, congestion control, and denial-of-service defenses. HTTP/3 also cannot make a slow application, distant origin, oversized page, or congested path fast by itself. Its benefit comes from removing protocol-induced waits: security setup is integrated with transport setup, request streams do not all stop behind one lost packet, and a working connection may persist across network changes. HTTP semantics stay recognizable while the machinery underneath is redesigned for modern encrypted, mobile Internet traffic.

Observability moves toward endpoints because much of the transport is encrypted. Operators measure handshake success, negotiated protocol, round-trip estimates, loss, fallback rates, response timing, and connection migration without expecting intermediate devices to inspect every control message. Load balancers need consistent handling of QUIC connection identifiers so packets for an active connection reach a server that holds its state. Version negotiation also lets future QUIC versions coexist, but implementations must reject spoofed downgrade attempts. Successful deployment is therefore an application, network, and operations project—not merely enabling a new protocol switch on one web server.

HTTP/3 carries HTTP messages over QUIC rather than TCP. Requests use independent QUIC streams, while control and QPACK streams manage settings and header compression. Key terms include QUIC, UDP, request stream, control stream, QPACK, multiplexing, head-of-line blocking, connection ID, and fallback.

No. Methods, status codes, fields, caching rules, and content retain their HTTP meaning. HTTP/3 changes the framing and transport used to move those messages, so applications can often support it without redesigning their resources.

UDP can be blocked, throttled, or poorly handled on some paths, and a QUIC handshake can fail for ordinary network reasons. A browser can then use an advertised alternative such as HTTP/2 over TLS and TCP.

Explore more "Explainers"

Discover additional explainers across politics, science, business, technology, and other fields. Each explainer breaks down a complex idea into clear, everyday language—helping you better understand how major concepts, systems, and debates shape the world around us.