Your spaceship has moved. Your opponent has fired. Somewhere in the network, an older message explaining where your spaceship used to be is still waiting for another attempt at delivery.
That message is accurate. It is also becoming less useful by the millisecond.
Real-time applications have an awkward problem: some information must arrive intact, while other information has an expiration date. A purchase confirmation and a constantly changing player position deserve different delivery rules.
WebTransport lets browser applications make that distinction, combining reliable streams with best-effort datagrams in a client-server session. Its most interesting feature is the ability to give different kinds of information different ways to travel.
WebTransport explained: three ways to move data
WebTransport is a browser API and a corresponding protocol framework for communication between clients and cooperating servers. This article focuses on WebTransport over HTTP/3, which uses QUIC over UDP. An HTTP/3 extended CONNECT request establishes the session; application data then travels through its streams and datagrams. [1, 2]
The application gets three useful building blocks: [1, 3, 4, 11]
| Building block | Delivery behavior | Example use |
|---|---|---|
| Unidirectional stream | Reliable, ordered bytes traveling in one direction | Server sends a map or a sequence of authoritative events |
| Bidirectional stream | Reliable, ordered bytes in each direction | Client and server exchange commands and responses |
| Datagram | A bounded message with no guarantee of delivery or arrival order | Frequent, replaceable position snapshots |
Reliable streams recover missing data while communication remains viable; connection failure can still interrupt them. Datagrams carried by QUIC’s DATAGRAM extension are not retransmitted by QUIC when lost. They remain encrypted and congestion-controlled. [3, 4]
If UDP’s message-oriented model is familiar, datagrams will make intuitive sense. WebTransport adds a browser-compatible, protected transport around the idea, alongside reliable delivery options.
Why a perfectly delivered message can still be a problem
WebSockets made persistent, two-way browser communication practical. Their message framing and reliable, ordered delivery remain an excellent fit for many applications. [5]
Consider a conventional WebSocket connection running over TCP. If a TCP segment is lost, later bytes on that connection wait for the missing bytes to be recovered before delivery to the application. A newer position update can end up waiting behind older data.
This is transport head-of-line blocking: delivery order creates a dependency even when the application would happily use the newer information immediately.
Now imagine a game publishing a fresh position every 20 milliseconds. An update that arrives 100 milliseconds late may already have five newer snapshots behind it. Those figures illustrate the design problem; they are not a measured WebTransport performance claim.
The developer can coalesce updates before sending them over a WebSocket. Once older bytes have entered that reliable transport, the application cannot simply ask TCP to skip them and deliver the later bytes first.
WebTransport offers another choice: send replaceable snapshots as datagrams and reserve reliable streams for information that needs recovery.
Build a tiny delivery policy for a browser game
Imagine Orbital Post, a browser game in which players pilot delivery ships around a crowded space station. It is a fictional example, but its communication needs are ordinary engineering problems.
The server and browser could divide traffic like this:
| Information | Suggested path | Application responsibility |
|---|---|---|
| Buy a cargo upgrade | Bidirectional reliable stream | Confirm the outcome; make retries safe with a request identifier |
| Chat messages | A separate reliable stream | Preserve conversational order and handle disconnects |
| Download a station map | Unidirectional reliable stream | Validate and assemble the received content |
| Current ship position | Datagrams | Include a sequence number; discard obsolete snapshots |
Suppose the browser receives position snapshot 102, then 104, then a delayed 103. If each snapshot contains a complete, usable state, it can apply 104 and discard 103. Missing 103 does not require the display to stop.
That assumption matters. If snapshot 104 only means “add three meters to the position in snapshot 103,” discarding 103 breaks reconstruction. A real protocol might use self-contained snapshots, periodic recovery points, or a deliberately designed delta-recovery mechanism.
Likewise, receiving a purchase command reliably does not prove that the server committed the purchase. The application still needs a response describing the result. Reconnection can leave the client uncertain, so identifiers and duplicate handling remain useful.
The transport supplies delivery tools. The application defines what a correct result means.
Independent streams help, but they still share a network
QUIC multiplexes streams without making every stream wait for missing bytes on another. If the map stream loses data, a chat stream whose required bytes have arrived can continue. Ordering still applies within each stream. A lost QUIC packet can also contain data from several streams, affecting each of those streams. [3]
All this traffic still competes for connection capacity and network bandwidth. Congestion can reduce the sending rate for streams and datagrams alike. Application-level dependencies can also recreate waiting: chat cannot progress if your code insists on finishing the map first.
Opening more streams therefore does not create more bandwidth. It gives the application better ways to organize work within the available capacity.
The same QUIC building blocks appear in other modern networking designs. Our MASQUE explainer follows traffic through an HTTP-based proxy tunnel. WebTransport applies related transport capabilities to browser-to-server application communication.
Streams are bytes; your messages need framing
Here is an easy migration mistake: treating each stream write as one message that the receiver will read in exactly one operation.
WebTransport’s reliable streams carry bytes. Two writes can arrive together in a read; one write can require multiple reads. A message-oriented application needs framing, such as a length prefix or a carefully specified delimiter format. [3]
Datagrams preserve individual message boundaries, but have a size limit. Check the negotiated API limit, exposed as maxDatagramSize, rather than assuming every connection accepts a fixed payload size. Oversized content belongs on a stream or needs an application-defined fragmentation and recovery scheme.
For Orbital Post, that suggests small position snapshots and a reliable stream for the much larger station map.
WebTransport vs. WebSockets: choose the delivery model
The useful comparison starts with the application’s needs:
- Chat, notifications, and conventional dashboards: WebSockets often provide the required reliable message exchange with a mature deployment ecosystem.
- Mixed reliable commands and replaceable live state: WebTransport over HTTP/3 offers a particularly useful combination of streams and datagrams.
- Several independent transfers within one session: Separate WebTransport streams can avoid unnecessary cross-stream delivery dependencies.
- Peer-to-peer communication or a complete browser audio/video stack: Evaluate WebRTC, which provides capabilities beyond WebTransport’s client-server transport role. [6]
There is also an important qualification to the TCP comparison: WebSockets can be bootstrapped over HTTP/3, as specified in RFC 9220. Changing the underlying binding does not turn a WebSocket into WebTransport’s multiple application streams and unreliable datagrams. A single WebSocket still exposes reliable, ordered messages. [7]
If you are exploring the history of persistent web connections, our HTTP Keep-Alives article provides background. Connection reuse, WebSocket messaging, and WebTransport’s delivery options address different parts of the communication problem.
The next bottleneck might be your own queue
An application can send datagrams and still feel painfully delayed if it accumulates a long queue of outdated snapshots before sending them.
For replaceable state, a useful policy is to retain the newest unsent snapshot instead of appending every intermediate version indefinitely. For important commands, apply bounded queues, flow control, and an explicit response to overload.
The browser’s Streams API provides mechanisms for expressing backpressure. Using those mechanisms helps coordinate producers and consumers; it does not choose a freshness policy for your application. [8]
This leads to a better performance question than “How many messages per second can we send?” Ask: How old is the state when the user finally sees it? Measure that alongside loss, queue growth, and recovery behavior.
What to check before deploying it
Browser support has improved substantially. WebTransport appears in Baseline 2026, making it relevant across current major browser releases. Older browsers and individual API features still require compatibility checks. Feature detection establishes that an API exists; a real connection attempt establishes whether the path works. [9]
Standards work is still progressing. At the technical review for this article on November 7, 2026, the W3C API’s published version was the July 30 Candidate Recommendation Snapshot. The HTTP/3 mapping was Internet-Draft 17, dated November 2. These are distinct standardization tracks, and neither status should be described as a final WebTransport standard. [1, 2]
HTTP/3 support alone is insufficient. The server endpoint and relevant intermediaries must support WebTransport, with compatible implementations. A site that serves ordinary HTTP/3 pages does not automatically accept WebTransport sessions.
Network policy can change the outcome. The HTTP/3 path uses UDP; permission to use HTTPS over TCP does not establish UDP reachability. There is also an HTTP/2 mapping under development, with different underlying delivery behavior. Do not assume a particular browser or library silently provides that fallback. Design and test your fallback explicitly. [10]
Identity remains an application concern. Validate permitted browser origins and authenticate and authorize application actions. The browser API does not automatically carry your normal login cookies into the WebTransport session. Encryption protects the connection; it does not decide who may buy an upgrade. [1, 2]
A sensible first deployment starts with one workload that benefits from the distinction: reliable commands plus replaceable state. Test it under loss, reordering, congestion, and disconnection, then compare the age of useful information with your existing implementation.
Orbital Post’s purchase confirmation still deserves careful delivery. Its ship positions deserve a chance to stay current. WebTransport gives those two needs room to coexist in the same session.
References and further reading
- W3C WebTransport, Candidate Recommendation Snapshot, July 30, 2026 — browser API, stream framing, datagram limits, and security model.
- WebTransport over HTTP/3, Internet-Draft 17, November 2, 2026 — session establishment, origin checks, and HTTP/3 mapping; work in progress.
- RFC 9000: QUIC — streams, ordering, and the scope of head-of-line blocking.
- RFC 9221: An Unreliable Datagram Extension to QUIC — datagram delivery and congestion control.
- RFC 6455: The WebSocket Protocol — message framing and the original TCP-based protocol.
- W3C WebRTC: Real-Time Communication in Browsers — peer connections, data channels, and media capabilities.
- RFC 9220: Bootstrapping WebSockets with HTTP/3 — WebSockets over an HTTP/3 stream.
- WHATWG Streams Standard — queues, producers, consumers, and backpressure.
- web.dev: Baseline 2026 — current cross-browser availability milestone.
- WebTransport over HTTP/2, Internet-Draft 15, July 6, 2026 — an alternative mapping under development; work in progress.
- Chrome for Developers: How to use WebTransport — browser implementation guide and the three communication primitives.
