WebTransport fills the UDP-shaped gap in the web platform

The two gaps the API is designed to close

The specification names its motivation as filling gaps in the web platform, and it names two of them precisely. There is a lack of a UDP-like networking API in the browser, which leaves applications that send high frequency, small messages without a transport that matches their shape. And there is a lack of a WebSocket-like API without head-of-line blocking, which matters for the same traffic, since a reliable, ordered stream forces a slow message to delay the ones behind it. WebTransport is the answer to both at once: an API that allows web applications to establish interactive, bidirectional, multiplexed network connections. The distinction from WebSocket is not that it is faster in general, it is that a connection can carry both a reliable ordered channel and an unreliable one at the same time, so a game can move its state on the unreliable channel and still have a dependable channel for commands.

Reliable streams and unreliable datagrams share one connection

The feature list is the API. WebTransport provides reliable streams and unreliable datagrams, and it adds encryption and congestion control on top of them, with bindings for QUIC and multiplexing with existing HTTP/3 connections. Multiplexing is the structural point. Because a WebTransport session can run alongside other traffic on the same HTTP/3 connection, an application is not forced to open a second connection for a second kind of traffic, and the cost of adding a low latency channel to an app that already fetches over HTTP/3 is lower than it looks. The other listed capability is the one that decides whether an application can be ported later: the ability to change transport without changing application code. The API is also described as extensible to other protocols, with TCP fallback and peer to peer named as examples of where it could go next.

Origin-based security is the part server implementers carry

The security model of the API is origin-based, which means the browser enforces who may open a connection, in the same spirit as the rules that already apply to a fetch or a WebSocket handshake. For a web application, the practical consequences are familiar in shape and unfamiliar in detail, because the transport is not HTTP request and response. A server that exposes a WebTransport endpoint has to decide how it authorises an origin, how long a session lives and what happens when a page from another origin tries to open one, and the specification repository treats that as a first-class concern. The presence of a security-questionnaire.md file in the tree, alongside a use-cases.md and a code of conduct, is a reminder that this is a document project with the same review machinery as any other W3C work, and that the threat model questions were asked in public rather than settled quietly in an implementation.

What the repository actually contains

This is a specification repository, and the layout says so. The Bikeshed source of the specification is index.bs, with supporting fragments in the include directory and additional explainer documents in the explainers directory, and the top-level explainer.md is the readable overview the README points at for more information. Use cases are collected in use-cases.md, and w3c.json carries the group and document metadata that the W3C publishing process expects. There is a .pr-preview.json for preview builds of pull requests, a CODE_OF_CONDUCT.md and a CONTRIBUTING.md for how to work on the document, and the samples directory holds the two example applications described below. The licence sits in a LICENSE.md file, and it is a custom terms document rather than one of the licences the hosting platform can classify, which is normal for a specification published under a document licence. There are no published releases in the repository, so the text moves in the main branch and the preview builds are the way to read a proposed change.

Trying it: the echo samples and where they run

The repository ships two samples, and both are deployed, so you can look at the behaviour before writing anything. The basic echo sample is available at a Chicago endpoint and an Amsterdam endpoint, and its source is in the samples/echo directory of this repository. The WebCodecs echo sample does the same round trip through the WebCodecs API, with deployed instances in Chicago and Amsterdam and its source in the samples/webcodecs-echo directory. Those two addresses are the quickest way to see what a WebTransport session feels like in a browser today:

https://wt-ord.akaleapi.net/echo/
https://wt-ams.akaleapi.net/echo/

The second sample matters because it pairs the transport with a media pipeline, and the point of an unreliable datagram channel is exactly that kind of traffic. A reader who wants to see the API surface rather than the demo should start with the proposed specification linked from the README, then read the explainer for the reasoning, then the use cases for the situations the design was built around.

Where the design is still open

Three things in the feature list are deliberately unfinished, and they are worth separating from the parts that are settled. The first is transport extension. The claim that the API is flexible enough to cover other protocols, with TCP fallback and peer to peer named as examples, describes a direction rather than a shipped mechanism, and a reader looking for a TCP fallback today will not find one described as part of the core API. The second is implementation. The repository contains no client or server library, no package to install and no releases, so adopting WebTransport in production means relying on browser support and on server implementations that exist elsewhere, and the direction of the specification is a useful guide for those implementations without being the implementation itself. The third is the split between the two homes of the document. The README links the proposed specification from the WICG while the repository itself sits under the W3C, which is a normal step in a standard's life but means there are two texts to check when you want to know which one is current.

Editorial conclusion

WebTransport is worth reading and prototyping with if you build anything on the web that needs more than request and response: game state, low latency media or file transfer. It is not a library you can add to a project, because the repository holds a specification rather than an implementation, and no releases have been published. Before spending time on it, check three things: the state of the spec, since the linked proposed specification lives with the WICG while this repository is the W3C home, and the difference between the two matters when you cite it; the security model, since the origin-based rules are what a server implementer has to get right before exposing a transport endpoint; and the transport assumptions, since the API is designed to be extended to TCP fallback and peer to peer work, and neither is settled here. The last push was on 2026-10-19, and the terms are in the LICENSE.md file rather than a licence the platform can classify.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. w3c/webtransport on GitHub