Skip to content

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

Closed

Description

@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

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.

Activity

  1. jasnell commented on Mar 28, 2026

    @jasnell
    Collaborator

    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

  2. locked and limited conversation to collaborators on Mar 28, 2026
  3. converted this issue into a discussion #6454 on Mar 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions