HTTP/3 vs HTTP/2 is mostly a transport question. Both versions let a browser run several request and response streams over one connection. HTTP/2 carries those streams over TCP. HTTP/3 maps HTTP semantics onto QUIC, a secure transport built over UDP.
That change does not rewrite methods, status codes or URLs. It changes how a connection starts, how independent streams react to packet loss, and how a session can survive a move between networks.
Standards check: This guide follows RFC 9113, RFC 9114, RFC 9000 and RFC 9204 as reviewed on 24 October 2026.
The short comparison
| Detail | HTTP/2 | HTTP/3 |
|---|---|---|
| Transport | TCP | QUIC over UDP |
| Encryption in normal browser use | TLS layered above TCP | TLS 1.3 integrated into QUIC |
| Multiplexing | HTTP streams share one ordered TCP byte stream | HTTP streams map to independent QUIC streams |
| Loss effect | A missing TCP segment can delay delivery for every HTTP stream on the connection | Lost data blocks the affected QUIC stream, not unrelated streams |
| Header compression | HPACK | QPACK |
| Network change | A new TCP connection is normally required | A validated QUIC path can keep the connection alive |
| Deployment | Widely supported through established TCP infrastructure | Requires QUIC support and usable UDP paths |
The table describes protocols, not a guaranteed page-speed result. Server location, congestion, content size, caching and application design can outweigh the version number.
What HTTP/2 already fixed
HTTP/2 replaced HTTP/1.1’s text framing with binary frames and added multiplexed streams. A browser no longer needs one connection for every in-flight request. Headers can be compressed with HPACK, and the server can interleave frames from several responses.
Those streams still travel inside one TCP connection. TCP presents an ordered byte stream to the application. If one packet is lost, TCP has to recover the missing bytes before it can deliver later bytes, even when those later bytes contain frames for a different HTTP stream.
This is transport-level head-of-line blocking. HTTP/2’s own stream scheduler and flow-control windows prevent one application stream from taking every resource, but they cannot make TCP deliver bytes out of order.
What QUIC changes for HTTP/3
HTTP/3 uses QUIC rather than TCP. RFC 9114 maps HTTP requests, responses and control data onto QUIC streams. QUIC provides reliable, ordered delivery within each stream without imposing that order across every stream in the connection.
If a packet carrying part of one response is lost, that response waits for recovery. Data that belongs only to other streams can continue to reach the HTTP layer. The connection still shares a congestion controller, so heavy loss can slow the whole connection. The improvement is narrower: unrelated streams do not wait solely for the missing bytes of one stream.
HTTP/3 uses QPACK for header compression. HPACK’s compression state assumes an ordered transport; copying that design directly would recreate blocking between QUIC streams. RFC 9204 defines separate encoder and decoder streams and mechanisms that balance compression efficiency against the risk of a request waiting for header state.
Connection setup is combined
With HTTP/2 over TLS, a client establishes TCP and then negotiates TLS before sending protected application data. QUIC combines its transport and cryptographic handshakes. RFC 9000 uses TLS for key negotiation but carries the handshake inside QUIC.
For a first connection, that integration can reduce duplicated setup work. For a resumed connection, QUIC can support 0-RTT application data. Zero-RTT is not free acceleration: replayable early data has security constraints, and servers must decide which requests are safe to accept. A browser, origin or intermediary may choose not to use it.
HTTP/3 encrypts more transport metadata than TCP plus TLS, but it does not hide every network fact. IP addresses, packet timing, sizes and other observable characteristics remain available to on-path networks.
QUIC can survive a network change
TCP identifies a connection through network addresses and ports. Moving a phone from Wi-Fi to cellular normally changes that tuple and requires a new connection.
QUIC uses connection IDs so a connection can continue after an address change. The new path is not trusted immediately. QUIC performs path validation, using challenge and response frames, before treating it as usable. This helps a mobile session continue without pretending that any packet from a new address is legitimate.
Migration is a protocol capability, not a promise that every application keeps every transfer alive. Clients and servers can limit migration, a network can interrupt UDP, and an application can still restart work for its own reasons.
Why HTTP/3 still falls back
QUIC uses UDP datagrams. Some enterprise firewalls, old routers and restrictive networks block or degrade UDP even while allowing web traffic over TCP. A well-behaved client therefore does not assume that an advertised HTTP/3 endpoint is reachable.
Origins commonly advertise HTTP/3 support while continuing to offer HTTP/2. Browsers can try QUIC and fall back to TCP when the path does not work. That coexistence is why enabling HTTP/3 is not the same as removing HTTP/2.
Middleboxes also see less of QUIC’s internal state because the transport is encrypted. That limits some older inspection techniques. Network operators need QUIC-aware telemetry rather than treating every unfamiliar UDP flow as disposable traffic.
When users may notice the difference
HTTP/3 is most likely to help when latency is high, packet loss occurs, many resources share a connection, or a device changes networks. A stable low-latency desktop connection may show little difference. A badly configured server can erase any transport advantage.
The browser’s developer tools can show the negotiated protocol, often as h2 or h3. That label proves which version carried the request. It does not prove that HTTP/3 made the page faster. A useful test compares repeated loads under controlled latency and loss, includes fallbacks, and checks server timing rather than relying on one stopwatch result.
Before deployment, verify the entire path:
- the origin or CDN supports HTTP/3 and presents a valid TLS configuration;
- UDP on the chosen port is reachable from representative networks;
- HTTP/2 remains available as a fallback;
- load balancers understand QUIC connection IDs and routing;
- monitoring distinguishes negotiation failures from ordinary application errors;
- performance tests include loss and mobile-network changes, not only a clean office connection.
For a related look at encrypted name resolution, read DNS over HTTPS vs DNS over TLS. HTTP/3 protects an HTTP connection; it does not by itself choose or secure the DNS resolver used before that connection begins.
