You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Support WebTransport API in workerd [Tracking Issue] #6451
Feature Request: Support WebTransport API in workerd [Tracking Issue]
Summary
Implement the WebTransport API in workerd to enable local development of Cloudflare Workers that use incoming WebTransport connections.
Note: This is a tracking issue to gauge interest and track progress. WebTransport may not yet be on the Workers runtime roadmap.
Motivation
WebTransport is a W3C Working Draft that provides reliable and unreliable data transport over HTTP/3 (QUIC). It offers several advantages over WebSockets:
Bidirectional streams — native support for ordered/unordered streams in both directions
Datagrams — support for unreliable, unordered message delivery
Lower latency — due to QUIC's handshake and connection migration capabilities
Browser support is strong: Chrome 97+, Firefox 114+, Edge 98+, and Safari (Technology Preview). The spec is targeting W3C Recommendation status in Q2 2026.
This issue tracks interest in WebTransport support for workerd/wrangler. This feature request is specifically about supporting incoming WebTransport connections in workerd for local development with wrangler.
Proposed Solution
Implement the WebTransport API surface in workerd:
WebTransport — the main constructor for incoming WebTransport sessions
This would unblock developers building real-time applications (gaming, live collaboration, IoT) who want to use workerd for local development before deploying to Cloudflare's edge.
we've discussed this a number of times and it's not currently on our priority list. A key challenge is that workers does not include a quic/http3 implementation and the semantics of WebTransport do not fit naturally into the workers invocation model. That's not to say we won't do this, it's just not on our radar currently. If we did choose to support it, it would likely follow a model similar to our Socket API which is set up to tunnel through an http proxy, which means the runtime itself would not actually be speaking quic.
Activity
jasnell commentedon Mar 28, 2026
we've discussed this a number of times and it's not currently on our priority list. A key challenge is that workers does not include a quic/http3 implementation and the semantics of WebTransport do not fit naturally into the workers invocation model. That's not to say we won't do this, it's just not on our radar currently. If we did choose to support it, it would likely follow a model similar to our
SocketAPI which is set up to tunnel through an http proxy, which means the runtime itself would not actually be speaking quic.Again, not ruling it out but not on the agenda.
/cc @danlapid @vy-ton