Feature Request: Support WebTransport API in workerd [Tracking Issue]

[kziemski]

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:

• Head-of-line blocking elimination — QUIC's stream multiplexing avoids TCP head-of-line blocking
• 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:

1. WebTransport — the main constructor for incoming WebTransport sessions
2. WebTransportBidirectionalStream — bidirectional streams (readable + writable)
3. WebTransportDatagramDuplexStream — unreliable datagrams
4. WebTransportSendStream / WebTransportReceiveStream — unidirectional streams

This would allow developers to test WebTransport-based Workers locally via wrangler dev, mirroring how WebSocket support is already implemented.

Technical Considerations

• WebTransport requires HTTP/3 (QUIC) at the transport layer
• workerd would need to accept HTTP/3 connections with WebTransport extension negotiation
• The SEC-WEBSOCKET handler pattern used for WebSocket support could serve as a reference
• Consider whether this requires a compat flag (e.g., webtransport)

References

• W3C WebTransport Specification
• Can I Use: WebTransport
• Cloudflare Workers Protocols
• Cloudflare MoQ (related QUIC/HTTP3 infrastructure)

Priority

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.

[jasnell]

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.

Again, not ruling it out but not on the agenda.

/cc @danlapid @vy-ton

[kziemski]

I agree i meant it to be a tracking issue.
and i put it in the workerd to track if and when will be supported as its supposed to be on wintertc roadmap.

as for the model I'm not sure why it wouldn't fit the invocation model but i defer.

The reason i brought it up is that it has coverage across browsers with the apple adding support to the latest.