WebTransport: Streams and Datagrams for Realtime over HTTP/3

Three important capabilities

WebTransport can carry:

bidirectional streams
unidirectional streams
datagrams

Streams are reliable.

Datagrams are unreliable: they can be lost, and the mechanism does not require retransmitting every packet.

That makes it possible to match the transport semantics to the kind of data.

Not all data is equally important

Imagine a game.

Chat

"meet at point B"

We want reliable delivery.

Inventory update

ammo: 30 -> 29

Correctness matters here too.

Player position

x=10
x=11
x=12
x=13

If x=11 is lost but x=13 arrives, retransmitting the old position may be pointless.

For that kind of traffic a datagram can be the better model.

reliable stream -> important ordered state
datagram        -> ephemeral latest-state update

Multiple streams

WebSocket gives one logical ordered channel.

If the application sends:

large file chunk
chat message
control message

everything goes through one application-level ordering model.

WebTransport lets you create independent streams.

session
├── stream A: file
├── stream B: chat
├── stream C: control
└── datagrams: positions

That limits unwanted dependencies between different classes of traffic.

QUIC removes transport-level head-of-line blocking between independent streams: losing data on one stream does not have to stop delivery on another.

The browser API

A simplified start:

const transport =
  new WebTransport("https://example.com:4433/wt");

await transport.ready;

From there we can create streams or use datagrams.

For example:

const stream =
  await transport.createBidirectionalStream();

const writer = stream.writable.getWriter();

This is a more stream-oriented API than WebSocket.send().

WebTransport is not "WebSocket v2"

WebTransport should not be chosen just because it is newer.

WebSocket:

simple
mature
widely understood
excellent for message-oriented full duplex

WebTransport:

multiple independent streams
unreliable datagrams
HTTP/3 / QUIC semantics
more transport choices exposed to application

More control means more decisions.

The application has to know which data:

• must arrive,
• must keep its order,
• can be dropped,
• deserves a stream of its own.

Support status

WebTransport is currently marked by MDN as Baseline 2026 and works in the current generations of the major browsers, but older clients may not support it.

That still matters when designing a product with a wide compatibility range.

WebTransport also needs infrastructure that supports HTTP/3 and WebTransport on the server side and along the network path.

When is it actually worth it?

A good signal is when plain:

bidirectional messages

is not precise enough.

For example, when we need all of these at once:

reliable ordered stream
+
independent file stream
+
loss-tolerant high-frequency updates

Then the WebTransport model starts to match the real data model.

For the classic:

chat
notifications
collaborative CRUD

WebSocket or SSE may remain the simpler solution.

So we have reached a point where several correct mechanisms exist.

The last question is no longer:

what can the platform do?

It is:

how do I pick the smallest mechanism that satisfies the requirements of our data flow?