WebTransport is the first browser API that gives a web page something UDP-like. This page explains what it actually provides, how it compares to the transports this API already runs, and the honest status of support — because a transport you can't deploy is a footnote, not a feature.
WebTransport is a W3C browser API layered on HTTP/3 (which runs over QUIC, which runs over UDP). A single WebTransport session gives a web page three primitives: bidirectional streams (reliable, ordered), unidirectional streams (reliable, one-way, cheap to open), and datagrams (unreliable, unordered, congestion-controlled — the UDP-like part browsers never had). It is secure-context-only, and the browser enforces Origin verification during the handshake.
The headline difference versus WebSocket: a WebSocket connection is one reliable ordered pipe — if packet N is lost, packet N+1 waits behind it (head-of-line blocking). WebTransport datagrams aren't queued behind anything, and independent streams don't block each other. For games, that's exactly the reliable/unreliable split a native UDP socket gives, wrapped in TLS and reachable from a web page.
Per MDN and caniuse: Chrome and Edge since 97, Firefox since 114, Safari since 26.4 (March 2026). WebTransport crossed the Baseline "Newly available" threshold in March 2026 — it works in the latest version of every major browser, but "latest" is doing real work: users on older Safari or locked-down embedded browsers get nothing.
The less visible half of support is the server. A WebTransport session needs an HTTP/3-capable endpoint — most general-purpose Node hosting, shared hosting and TLS-terminating proxies don't terminate HTTP/3 for application protocols yet. The client API being green on caniuse does not mean a deployable service exists behind it.
The realtime relay at realtime.michitai.com already provides the same reliable/unreliable split with proven infrastructure: a WebSocket control lane for reliable ordered messages (lobby events, actions, chat-class traffic) and a companion UDP channel — the MUR1 protocol — for unreliable, unsequenced high-frequency traffic like positions and inputs.
Native clients (Unity, .NET, Java, Python, C++, Node.js via the JavaScript SDK) can use both lanes. Browser clients use the WebSocket lane; the server automatically delivers UDP-sourced traffic to unbound web peers over their WebSocket. You get the full feature set in the browser today — the only thing missing is the unreliable sender path.
| Property | WebSocket (this API) | UDP/MUR1 (this API) | WebTransport |
|---|---|---|---|
| Delivery | Reliable, ordered | Unreliable, unordered | Both modes in one session |
| Browser sender | Yes | No (no browser UDP API) | Yes (Baseline 2026) |
| Native sender | Yes | Yes | Via HTTP/3 client libs |
| Server requirement | Any HTTPS host | UDP port on the relay | HTTP/3 endpoint |
It matters for one scenario: a browser game that must send unreliable, loss-tolerant traffic at high rate — a fast .io game streaming cursor positions, an arena shooter's aim state. For reliable traffic it's a wash versus WebSocket; for native games it adds nothing over the UDP lane that already exists. If your game is turn-based, co-op, party, card, trivia or slower-paced, the WebSocket lane is already sufficient and WebTransport changes nothing observable.
The engineering bar is real: deploying WebTransport means running an HTTP/3 session endpoint, handling stream/datagram lifecycle, origin checks and backpressure, plus a fallback for the sizeable share of clients still behind proxies that strip HTTP/3 or browsers without support. It is a significant server change — not a client-side upgrade you toggle on.
Not offered today. The relay has no HTTP/3 endpoint, and we won't publish a transport claim we haven't deployed and benchmarked. WebTransport is on the roadmap radar with explicit adoption criteria: measurable benefit for browser senders over the WS lane, a fallback path for unsupported clients, and parity with the existing room ACL and token model.
For browser multiplayer that works now, see WebGL & browser games and the JavaScript SDK — the realtime client abstracts the lane choice so a future WebTransport path wouldn't change your game code's shape.
