Articles

Check HTTP/3 Support Across Browsers and Test It (2026)

April 18, 2026 5 min read

HTTP/3 is already widely supported by major browsers and is often enabled by default, meaning you’re likely using it without even realizing it.

Let’s see it in action. Imagine you’re fetching a webpage. Without HTTP/3, your browser might establish a TCP connection, then an TLS handshake, and then send your HTTP request. With HTTP/3, it uses QUIC, which bundles the transport (like TCP) and TLS handshakes into a single round trip, and then sends the HTTP request. This is a significant speedup, especially on networks with higher latency.

Here’s how you can check if your browser is using HTTP/3 for a specific website.

First, open your browser’s developer tools. In Chrome, you can press F12 or Cmd+Option+I. Navigate to the "Network" tab.

Now, go to a website that you know supports HTTP/3. A good test site is cloudflare.com. Reload the page while the developer tools are open.

In the "Network" tab, you’ll see a list of all the resources being loaded. Look for a column labeled "Protocol." If you don’t see it, right-click on the table headers (like "Name," "Status," "Type") and select "Protocol" to enable the column.

You should see h3 or http/3 listed for many of the resources loaded from cloudflare.com. If you see h2 (HTTP/2) or http/1.1, then HTTP/3 is not being used for those specific resources.

Browser Support Status (as of late 2023/early 2024):

  • Chrome: Supports HTTP/3. It’s generally enabled by default.
  • Firefox: Supports HTTP/3. It’s generally enabled by default.
  • Edge: Supports HTTP/3 (as it’s based on Chromium). It’s generally enabled by default.
  • Safari: Supports HTTP/3. It’s generally enabled by default.

How to Test and Enable (if needed):

While usually enabled, sometimes network configurations or specific browser flags can interfere.

  1. Verify Browser Flags (Chrome/Edge):

    • Open a new tab and type chrome://flags or edge://flags in the address bar.
    • Search for "HTTP/3".
    • Ensure that "Experimental QUIC protocol" or "HTTP/3 (spdy+quic)" is set to "Enabled."
    • Relaunch your browser.
    • Why it works: This directly toggles the underlying QUIC protocol implementation within the browser, which is the transport layer for HTTP/3.

  2. Verify Browser Flags (Firefox):

    • Open a new tab and type about:config in the address bar.
    • Accept the risk if prompted.
    • Search for network.http.http3.enabled.
    • Double-click the entry to set its value to true.
    • Search for network.quic.enabled.
    • Double-click the entry to set its value to true.
    • Relaunch your browser.
    • Why it works: These preferences control Firefox’s decision to use HTTP/3 and its underlying QUIC transport mechanism.

  3. Use Online Test Tools:

    • Websites like https://gf.dev/http3-test can check your connection to a specific domain for HTTP/3 support.
    • Why it works: These tools act as a client-side simulator, attempting to establish an HTTP/3 connection to the target server from your network, reporting success or failure.

  4. Check Server-Side Configuration:

    • If you control the web server, ensure it’s configured to support HTTP/3. This typically involves having an up-to-date web server (like Nginx with QUIC support, Caddy, or Cloudflare’s edge) and enabling the HTTP/3 module.
    • For Nginx, you’d typically need a version compiled with ngx_http_v2_module and ngx_http_v3_module (which often depends on BoringSSL or OpenSSL 3.0+ with QUIC support). The configuration would involve directives like listen 443 http2 quic reuseport; and ssl_protocols TLSv1.3;.
    • Why it works: The server must explicitly advertise its support for HTTP/3 (via ALPN during the TLS handshake) and be capable of handling QUIC connections, which is a different protocol than TCP.

  5. Network Interference:

    • Some firewalls or network devices might block UDP port 443, which QUIC (and thus HTTP/3) uses. Standard HTTPS uses TCP port 443.
    • Diagnosis: Temporarily disable VPNs or proxies. If you’re on a corporate network, consult your IT department. You can also try testing from a different network (e.g., mobile hotspot vs. home Wi-Fi).
    • Why it works: Bypassing restrictive network elements allows the UDP packets for QUIC to reach their destination, enabling the HTTP/3 connection.

The most surprising thing about HTTP/3 is that it doesn’t use TCP at all; instead, it runs over QUIC, a new transport protocol built on UDP. This shift is fundamental because it allows HTTP/3 to overcome the "head-of-line blocking" problem inherent in TCP. In TCP, if a packet is lost, all subsequent packets in that connection have to wait for retransmission, even if they’ve arrived. QUIC, by multiplexing streams at the transport layer itself, can deliver packets for one stream independently of others, significantly improving performance on lossy networks.

When you see h3 in your developer tools, it signifies that your browser successfully negotiated an HTTP/3 connection with the server using the QUIC transport protocol. This implies that the TLS handshake and the initial connection setup were likely faster than a traditional TCP-based HTTP/2 or HTTP/1.1 connection, especially if there was any packet loss or latency involved.

The next step after confirming HTTP/3 support is understanding how to optimize your own web server for it, which involves careful configuration of your web server software and ensuring your network infrastructure permits UDP traffic on port 443.

Want structured learning?

Take the full Http3 course →