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

> WebTransport explained: one multiplexed HTTP/3 connection with reliable streams and unreliable datagrams. How it works, support and standards status.

URL: https://webtransport.day/guides/what-is-webtransport/
Updated: 2026-10-28
Facts checked: 2026-10-28

**Short answer:** WebTransport is a browser API and protocol framework for opening one secure, multiplexed connection to a server, today over HTTP/3, and sending data on many independent reliable streams plus unreliable datagrams. It is built on QUIC. Browsers expose it as the WebTransport class, available only in secure contexts.

## Key facts

- **Protocol:** WebTransport over HTTP/3 (IETF draft-ietf-webtrans-http3, draft-16 when checked)
- **Transport:** QUIC, over UDP
- **W3C status:** Candidate Recommendation Snapshot, 30 July 2026
- **Browser support:** Chrome 97, Firefox 114, Safari 26.4 (MDN); Edge follows Chromium
- **Requires:** A secure context (HTTPS)

## 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 <Term slug="http-3">HTTP/3</Term>, which runs on <Term slug="quic">QUIC</Term>, which runs on <Term slug="udp">UDP</Term>.

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 <Term slug="extended-connect">extended CONNECT</Term> 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.


The [handshake debugging guide](/guides/debug-webtransport-handshake-errors/) 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.
- **<Term slug="datagram">Datagrams</Term>.** Small, unreliable, unordered messages. QUIC datagrams are not retransmitted when lost (RFC 9221), though they are still congestion-controlled.


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:

```js
// 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](/tools/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.


## 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](/guides/webtransport-client-libraries/) 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](/guides/webtransport-vs-websocket/) for a sourced comparison.

## How do I try it?

Open the [WebTransport tester](/tools/webtransport-tester/) and connect to an echo server. Find one on the [echo server page](/echo-server/), or [run one locally](/guides/test-webtransport-locally/).

## FAQ

### Is WebTransport a standard yet?

The W3C WebTransport API is a Candidate Recommendation Snapshot (30 July 2026). WebTransport over HTTP/3 is still an IETF Internet-Draft (draft-ietf-webtrans-http3-16 when checked), not an RFC.

### Which browsers support WebTransport?

MDN lists Chrome 97, Firefox 114 and Safari 26.4 as the first versions with the API, and marks it Baseline 2026, newly available since March 2026. caniuse reports Edge 98 and later.

### Does WebTransport replace WebSocket?

Not as a drop-in. It offers multiple streams and datagrams and avoids cross-stream head-of-line blocking, but WebSocket has a more mature server ecosystem and broader compatibility. See the comparison guide.

### Can WebTransport run over HTTP/2?

An HTTP/2 binding is specified in a separate IETF draft for fallback, but the transport the API is best known for is HTTP/3 over QUIC. A client can set requireUnreliable to forbid a fallback that cannot send unreliable datagrams.

## Sources

- [W3C: WebTransport (Candidate Recommendation Snapshot, 30 July 2026)](https://www.w3.org/TR/webtransport/)
- [MDN: WebTransport API](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API)
- [MDN: WebTransport interface](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport)
- [Chrome for Developers: How to use WebTransport](https://developer.chrome.com/docs/capabilities/web-apis/webtransport)
- [IETF draft-ietf-webtrans-http3: WebTransport over HTTP/3](https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/)
- [IETF draft-ietf-webtrans-overview](https://datatracker.ietf.org/doc/draft-ietf-webtrans-overview/)
- [RFC 9000: QUIC](https://www.rfc-editor.org/rfc/rfc9000)
- [RFC 9114: HTTP/3](https://www.rfc-editor.org/rfc/rfc9114)
- [RFC 9221: An Unreliable Datagram Extension to QUIC](https://www.rfc-editor.org/rfc/rfc9221)
- [RFC 9297: HTTP Datagrams and the Capsule Protocol](https://www.rfc-editor.org/rfc/rfc9297)
- [Can I use: WebTransport](https://caniuse.com/webtransport)