What is WebTransport? Streams, datagrams, HTTP/3 and QUIC explained

What is WebTransport?

WebTransport lets a web page or app open one secure connection to a server and then send and receive data on many independent streams, plus unreliable datagrams, over that one connection. In browsers it appears as the WebTransport JavaScript class. Servers speak it over HTTP/3, which runs on QUIC, which runs on UDP.

Think of it as a general-purpose, client-to-server transport that sits between WebSocket (one ordered, reliable stream) and raw UDP (unreliable packets, but no browser access).

How does a WebTransport connection start?

The browser first establishes a QUIC connection and an HTTP/3 session with the server. It then sends an HTTP/3 extended CONNECT request to the URL you gave. If the server answers with a 2xx status, the request stream becomes a WebTransport session, and both sides can open streams and send datagrams that belong to it.

Some details from the IETF draft that explain common failures:

• The server must signal support through HTTP/3 settings (extended CONNECT and HTTP Datagrams, plus the WebTransport setting) and allow QUIC datagrams. If it does not, clients must not start a session.
• Browsers include an Origin header, and a server can reject unwanted origins (the draft suggests a 403 response).
• A server can reject a path it does not serve (405 is suggested), and clients do not follow redirects (3xx) for this request.

Text version

1. QUIC handshake with TLS 1.3 (over UDP). The server certificate is checked here.
2. HTTP/3 SETTINGS from the server. Extended CONNECT, HTTP Datagrams and WebTransport are enabled.
3. Extended CONNECT request for the URL. :scheme https, :authority, :path and an Origin header.
4. 2xx response: session accepted. Other statuses, such as 403 or 405, reject the session.
5. Session open. Streams (reliable) and datagrams (unreliable) flow both ways.

The handshake debugging guide turns these into a checklist.

What are streams and datagrams?

A WebTransport session carries three kinds of data flow:

• Bidirectional streams. Either side can send and receive. Bytes arrive reliably and in order within the stream. This is the closest match to a WebSocket message flow.
• Unidirectional streams. One side sends, the other receives. Useful for one-shot messages or server push.
• Datagrams. Small, unreliable, unordered messages. QUIC datagrams are not retransmitted when lost (RFC 9221), though they are still congestion-controlled.

Text version

• Streams (blue): three independent streams each deliver messages 1, 2, 3 reliably and in order. A stream does not wait for another stream. QUIC retransmits lost data.
• Datagrams (amber): messages A, B, C, D are sent. B is lost (coral dashed outline) and D arrives before C. Datagrams are not retransmitted.

Streams are independent: QUIC does not impose ordering across streams (RFC 9000), so a lost packet delaying one stream does not block the others. That property is the main reason people compare it favourably with a single TCP connection.

In the browser, streams use the standard Streams API (ReadableStream, WritableStream), including backpressure.

What does the API look like?

This is a minimal client example. The URL is a placeholder, not a live server:

// Example only: replace the URL with a server you control.
const transport = new WebTransport('https://example.com:4433/echo');
await transport.ready;

const stream = await transport.createBidirectionalStream();
const writer = stream.writable.getWriter();
await writer.write(new TextEncoder().encode('hello'));
await writer.close();

const reader = stream.readable.getReader();
const { value } = await reader.read();
console.log(new TextDecoder().decode(value));

transport.close();

transport.ready resolves when the session is established; transport.closed settles when it ends. The URL must use https. You can try this against a server of your choice with the WebTransport tester.

What states does a WebTransport session go through?

The W3C specification defines five internal session states: connecting, connected, draining, closed and failed. They are not exposed as a public state attribute; you observe them through the ready, closed and draining promises. A session starts in connecting. It becomes connected when ready resolves, and it can fail if setup fails or the network breaks. When the server asks for a graceful wind-down the session is draining, which still works but should be wrapped up soon.

Text version

From	To	When
connecting	connected	The ready promise resolves.
connecting	failed	Setup fails: ready and closed reject.
connected	draining	The server asks the session to close gracefully and the draining promise resolves. The session still works; finish up.
draining	closed	The session ends and closed resolves.
connected	closed	close() is called or the peer closes: closed resolves.
connected	failed	A network error ends the session: closed rejects.

What is the standards status of WebTransport?

Status as checked on 28 October 2026; the standards documents change, so see the linked sources for the current state.

• W3C API: Candidate Recommendation Snapshot dated 30 July 2026, with a newer Editor’s Draft maintained on GitHub.
• IETF protocol: WebTransport over HTTP/3 is draft-ietf-webtrans-http3 (draft-16, dated 6 July 2026, when we checked). It is in working-group last call and is not yet an RFC. The related overview draft has the same status.
• Building blocks that are RFCs: QUIC (RFC 9000), HTTP/3 (RFC 9114), QUIC datagrams (RFC 9221) and HTTP datagrams (RFC 9297).

Because the protocol draft has changed over time, a server written for an older draft may not interoperate with a current browser. Check which draft your library implements; the libraries guide records what each project states.

Which browsers support WebTransport?

As checked on 28 October 2026, MDN labels the API Baseline 2026 “newly available”, meaning it works across the latest browser versions since March 2026. Its compatibility data lists these first versions:

| Browser | First version with the API (per MDN) | |---|---| | Chrome | 97 | | Firefox | 114 | | Safari | 26.4 | | Edge | follows Chromium (caniuse: 98) |

Some options have narrower support, for example serverCertificateHashes (Chrome 100, Firefox 125, Safari 26.4 per MDN data) and the congestionControl option (limited availability). The API requires a secure context and is available in Web Workers. Always feature-detect with 'WebTransport' in window.

How is it different from WebSocket and WebRTC?

WebSocket gives you one reliable, ordered message stream per connection. WebRTC data channels are peer-to-peer and need ICE, DTLS and SCTP. WebTransport is client-to-server, supports multiple streams and datagrams, and has a simpler server story on top of HTTP/3. See WebTransport vs WebSocket for a sourced comparison.

How do I try it?

Open the WebTransport tester and connect to an echo server. Find one on the echo server page, or run one locally.