How Browsers Decide Whether to Use HTTP/3

2026-07-29T00:00:00+10:00

There is no HTTP/3 switch inside the TLS handshake.

HTTP/1.1 and HTTP/2 both run over TCP. A browser can open TCP port 443, start TLS and use ALPN to choose between http/1.1 and h2. HTTP/3 runs over QUIC, which uses UDP. By the time a normal TLS-over-TCP handshake begins, the browser has already chosen the wrong transport for HTTP/3.

It has to learn that a QUIC endpoint exists first. Then it has to decide whether that information is worth acting on.

Those are separate problems. The discovery mechanisms are covered by standards. The exact decision to wait for DNS, start TCP, race QUIC, abandon a slow attempt or remember a failure is not.

That distinction explains why two browsers can visit the same site from the same network and use different HTTP versions without either one being broken.

Two ways to advertise HTTP/3

The older and more common route is an Alt-Svc response header:

Alt-Svc: h3=":443"; ma=86400

RFC 9114, the HTTP/3 specification, says an origin can advertise an equivalent HTTP/3 endpoint this way. The browser receives the header over an existing HTTP/1.1 or HTTP/2 connection, stores the alternative service and may try QUIC.

The catch is in the sequence. On a first visit, the browser needs an HTTP response before it sees the header. That first connection is already on TCP. A later request can use the cached HTTP/3 alternative.

DNS can provide the information earlier. RFC 9460 defines SVCB and HTTPS resource records. An HTTPS record can advertise ALPN protocols, ports, address hints and alternative endpoints:

example.com. 300 IN HTTPS 1 . alpn="h3,h2"

A browser that receives this record in time can attempt HTTP/3 on the first visit. It does not need to make an HTTP/2 request just to discover that HTTP/3 exists.

Neither advertisement proves that QUIC will work. UDP 443 may be blocked by a firewall, filtered by a corporate network or mishandled somewhere between the user and the edge. The certificate and authority still need to check out. The browser eventually has to test the path.

The standard stops before the interesting bit

RFC 9114 permits a client to try an advertised HTTP/3 service. If QUIC cannot be established, it recommends trying a TCP-based HTTP version. It does not set the browser's race timer or say how long a failed endpoint should remain suspect.

RFC 9460 is similarly careful. It gives the client a set of service endpoints and parameters. It allows TCP and QUIC attempts when the advertised ALPN set supports both. It does not prescribe one universal ordering algorithm.

So there is a standard for saying “HTTP/3 is available here”. There is no standard that says every browser must:

wait the same amount of time for an HTTPS DNS answer;
start QUIC before TCP;
race both immediately;
prefer the same IPv4 or IPv6 endpoint; or
retry a failed QUIC path after the same interval.

Those choices belong to the implementation. They also change.

What Chromium currently does

Chromium source shows why a neat flowchart quickly becomes misleading.

In its established connection path, Chromium can create separate jobs for the ordinary TCP route, a cached Alt-Svc alternative and an HTTP/3 endpoint learned through DNS. The HTTP stream job controller starts the alternative jobs and manages their competition with the main job.

The Alt-Svc information is not rediscovered on every request. Chromium reads it from its stored HTTP server properties, ignores alternatives already marked broken and can create a QUIC attempt from the remaining entry.

That last part matters. If the TCP job succeeds while HTTP/3 fails, Chromium can mark the alternative service as broken. Some failures are treated as specific to the current network and reconsidered after the default network changes. A failed QUIC attempt at the office does not have to poison HTTP/3 after the laptop moves to another network.

DNS discovery is conditional too. The legacy path checks that HTTPS-record ALPN support and QUIC are enabled, that the request is HTTPS, that the connection is direct rather than proxied, and that the DNS alternative is not already marked broken. Merely publishing alpn="h3" does not force Chrome to use it.

Current Chromium also contains a separate Happy Eyeballs v3 connection-pool path. When that path is enabled and eligible, the request leaves the older job-controller sequence. This is a useful warning for anyone interpreting packet captures: “Chrome races these three jobs in this order” may accurately describe one build and be wrong for another.

The durable conclusion is narrower. Chromium gathers candidates, uses remembered success and failure, and is prepared to let TCP and QUIC compete. The timings and plumbing are implementation details.

Firefox makes different choices

Firefox also has explicit HTTP/3 fallback policy rather than a simple protocol preference.

Mozilla's current preferences enable HTTP/3 and fallback to HTTP/2 on error. Its networking code can consume Alt-Svc advertisements and use a DNS HTTPS record as an Alt-Svc-like input.

That DNS path has conditions. In nsHttpChannel, HTTPS-record use depends on such things as the DNS strategy, proxy use, Firefox's encrypted-DNS mode and whether the current network has been judged able to resolve HTTPS records. In some circumstances Firefox waits for the record; in others it proceeds without making the request hostage to that answer.

When Firefox chooses an HTTP/3 endpoint learned from DNS, nsHttpTransaction has a fast-fallback path to a backup connection. After a failed HTTP/3 attempt it can also remove H3-capable SVCB candidates before retrying. If Firefox already has a usable HTTP/3 connection, the connection manager tries to dispatch work there before HTTP/2.

That is a real preference, but it is not a promise that every fresh Firefox connection starts with QUIC. Cached state, proxy configuration, DNS-over-HTTPS status and the current network all affect the choice.

What Apple documents, and what it does not

Apple's HTTP/3 technote recommends an HTTPS DNS record with alpn="h3,h2" for service discovery. It also supports Alt-Svc and explains the practical difference: DNS can make HTTP/3 available on the first transaction, while an Alt-Svc-only client may use HTTP/2 first and apply the remembered advertisement on a later request.

Apple also documents fallback to HTTP/2 or HTTP/1.1 when HTTP/3 is unavailable on the server or network.

That is good deployment guidance. It is not a published Safari endpoint-selection algorithm. WebKit is open source, but much of the Apple platform networking behaviour involved here sits below the rendering engine. We should not turn one Safari test on one release and operating system into a claim about every Apple device.

If Safari on macOS and Safari on iPadOS behave differently in a lab, record the versions, resolver, network and cache state. The difference is evidence worth investigating, not a new browser law.

DNS timing can decide the winner

An HTTPS record is useful only if the browser receives and uses it soon enough.

A, AAAA and HTTPS answers may arrive through different resolver paths and at different times. The browser can wait for more complete endpoint information or begin connecting with the address it already has. Waiting can produce a better candidate set. It can also add visible delay when the missing answer never arrives.

This is one reason browser traces vary with the operating system and DNS configuration. Chrome and Firefox both have internal DNS behaviour, but either can be affected by platform resolver choices, encrypted-DNS settings, proxies, caches and experiment flags.

RFC 10029, DNS Multiple QTYPEs, was published in July 2026 to let a DNS client request additional record types alongside its primary query. A client could ask for A, AAAA and HTTPS information and receive a combined response instead of waiting for three independently timed answers.

That removes one possible source of timing skew. Publication does not mean browsers, resolvers and authoritative servers support it yet. It also cannot make a blocked UDP path work.

Happy Eyeballs is growing beyond IPv4 versus IPv6

Happy Eyeballs originally dealt with a familiar failure: an IPv6 address exists, but the IPv6 path is slow or broken. Rather than make the user wait for a timeout, the client tries another candidate.

The active Happy Eyeballs Version 3 Internet-Draft generalises that work. Its candidate model can account for service endpoints, transport protocols and ALPN, not only IPv6 and IPv4 addresses.

That is the right shape for HTTP/3. A browser may be choosing among:

HTTP/3 over QUIC to an IPv6 address;
HTTP/3 over QUIC to an IPv4 address;
HTTP/2 over TLS and TCP to either address; and
endpoints with different priorities or ports from an HTTPS record.

Version 3 is still an Internet-Draft, not a finished standard. Chromium having a feature called Happy Eyeballs v3 does not mean its current behaviour is the final IETF algorithm, and it does not mean other browsers use the same timers.

What operators should do

Advertise HTTP/3 with both DNS HTTPS records and Alt-Svc.

The HTTPS record gives capable clients a chance to use QUIC on the first connection. Alt-Svc reaches clients that learn alternatives through HTTP responses and provides a second discovery path. Keep HTTP/2 working on TCP 443 because HTTP/3 is an additional path, not a safe replacement for fallback.

Then measure the versions separately. At the edge, record the negotiated HTTP version, QUIC handshake success, fallback rate, network and browser family. Test from clean profiles as well as warm ones: cached Alt-Svc and remembered QUIC failures can completely change the result.

When a test surprises you, capture more than the browser name. Record:

browser and operating-system versions;
whether the profile was new or had visited before;
the A, AAAA and HTTPS answers actually returned;
Alt-Svc value and cache lifetime;
whether UDP 443 worked on that network; and
whether a proxy, VPN or encrypted-DNS mode was active.

Cloud Fellows' protocol-negotiation and DNS HTTPS versus Alt-Svc test notes are useful examples of why those details matter. Their observations should be read as measurements of named configurations, not a substitute for browser specifications.

HTTP/3 discovery has standards. Browser connection strategy is still a moving piece of software. For operators, the sensible response is not to predict one universal race. Advertise both paths, preserve fallback and measure what clients actually do.

Peakhour.IO - HTTP/3