What is HTTP/3? A plain explanation
The newest version of HTTP runs on QUIC, a transport built on UDP instead of TCP. Here's what changes — and why pages feel faster with it.
On this page
- The problem: HTTP/2 head-of-line blocking
- What HTTP/3 changes: QUIC instead of TCP
- What else QUIC brings
- Same HTTP, new transport
- A bit of history
- Who supports it
- FAQ
- What is HTTP/3?
- What is head-of-line blocking and how does HTTP/3 fix it?
- What are the main benefits of QUIC?
- Which browsers and servers support HTTP/3?
- Summary
HTTP/3 is the third major version of the Hypertext Transfer Protocol. Instead of running over TCP like HTTP/1.1 and HTTP/2, it runs over QUIC — a secure, multiplexed transport protocol built on UDP. Its biggest practical win: a lost packet no longer stalls an entire page load.
The problem: HTTP/2 head-of-line blocking
HTTP/2 made pages faster by multiplexing — many requests and responses travel at the same time over one TCP connection. Sounds perfect, but TCP has a blind spot: its loss-recovery mechanisms cannot see the multiplexing above them. When one packet is lost, TCP waits for it to be retransmitted, and every stream sharing that connection stalls until it arrives. That is head-of-line blocking.
What HTTP/3 changes: QUIC instead of TCP
HTTP/3 keeps the HTTP semantics — the same request methods, status codes and header fields — but maps them onto a different transport. QUIC is a connection-oriented, secure transport protocol that provides stream-based multiplexing natively. Because multiplexing lives inside the transport itself, a lost packet only affects the streams that actually lost data. The other streams keep flowing.
QUIC also integrates the TLS handshake directly, using TLS 1.3. Encryption and connection setup happen together, and the handshake is designed so that application data can be exchanged as soon as possible — including a 0-RTT option for reconnects.
What else QUIC brings
- Connection migration — a QUIC connection is identified by a connection ID rather than by the IP address, so the connection survives when a phone switches from Wi-Fi to mobile data.
- Faster reconnects — the 0-RTT option lets a client that connected before send data immediately on a new connection.
- Fewer round trips — the combined handshake replaces the separate TCP and TLS round trips of older versions.
Same HTTP, new transport
Nothing about the web's model changes: browsers still use https:// URLs, and servers still answer with HTTP status codes and headers. HTTP/3 is just a different way of carrying those messages. Clients discover an HTTP/3-capable server through mechanisms like the Alt-Svc header or the HTTPS DNS record, then open a QUIC connection.
A bit of history
HTTP/3 started as an IETF draft called "HTTP/2 Semantics Using The QUIC Transport Protocol". In November 2018 it was renamed HTTP/3, to make clear it is another binding of HTTP semantics to a wire protocol, separate from QUIC itself. The standard was published in June 2022 as RFC 9114, with QUIC defined in RFC 9000.
Who supports it
All major browsers ship HTTP/3 enabled by default: Chrome and Edge since 2020, Firefox since 2021, and Safari since version 16.4 (September 2024). On the server side, Caddy enabled it by default in its 2.6 release (2022), nginx supports it since 1.25 (2023), and LiteSpeed enabled it by default back in 2021. Your browser's developer tools show the protocol used by each request — look for h3 in the network tab.
FAQ
What is HTTP/3?
HTTP/3 is the third major version of HTTP. Unlike HTTP/1.1 and HTTP/2 which run over TCP, HTTP/3 runs over QUIC — a secure, multiplexed transport protocol built on UDP. This means a lost packet no longer stalls the entire page load.
What is head-of-line blocking and how does HTTP/3 fix it?
In HTTP/2, multiplexing happens over a single TCP connection. When one packet is lost, TCP waits for retransmission and all streams on that connection stall — this is head-of-line blocking. HTTP/3 moves multiplexing into QUIC itself, so a lost packet only affects the streams that actually lost data; other streams keep flowing.
What are the main benefits of QUIC?
QUIC brings three key improvements: (1) Connection migration — connections are identified by a connection ID, not IP address, so they survive network changes like switching from Wi-Fi to mobile data. (2) Faster reconnects — the 0-RTT option lets a previously connected client send data immediately on a new connection. (3) Fewer round trips — the combined TLS 1.3 handshake replaces the separate TCP and TLS handshakes of older versions.
Which browsers and servers support HTTP/3?
All major browsers ship HTTP/3 enabled by default: Chrome and Edge since 2020, Firefox since 2021, and Safari since version 16.4 (September 2024). On the server side, Caddy enabled it by default in 2.6 (2022), nginx supports it since 1.25 (2023), and LiteSpeed has had it enabled by default since 2021. You can check the protocol in your browser's developer tools — look for h3 in the network tab.
Summary
HTTP/3 is HTTP over QUIC: the same web protocol you already use, carried by a transport that multiplexes without head-of-line blocking, encrypts by default, and survives network changes. It is not a new language for the web — it is the same language, delivered more efficiently.
Sources
- RFC 9114 — HTTP/3 (rfc-editor.org/rfc/rfc9114)
- RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport (rfc-editor.org/rfc/rfc9000)
- Wikipedia — HTTP/3 (en.wikipedia.org/wiki/HTTP/3)
- MDN — Evolution of HTTP (developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Evolution_of_HTTP)
- MDN — HTTP/3 glossary (developer.mozilla.org/en-US/docs/Glossary/HTTP_3)
Share this guide
Related guides
- What is a CDN? A plain explanation
Why web pages load fast everywhere: how content delivery networks cache files at the edge, route visitors to the nearest server, and protect sites from attacks.
- TCP vs UDP: what's the difference?
TCP and UDP are the two main ways data travels over the internet. TCP is reliable but slower; UDP is fast but lossy. Here's when each one is used.
- What are WebSockets? A plain explanation
WebSockets keep a two-way connection between browser and server open, so either side can send data any time. Here's how the handshake, frames, and close codes work — and when to use them.