wtransport: a Rust WebTransport implementation with a browser on the other end

What WebTransport is for, and why HTTP and WebSocket are not enough

WTransport is the WebTransport protocol, pure Rust, async-friendly, and the README starts by explaining the protocol rather than the library.

WebTransport is a new protocol being developed to enable low latency, bidirectional communication between clients and servers over the web. It aims to address the limitations of existing protocols like HTTP and WebSocket by offering a more efficient and flexible transport layer.

The benefits list gives the shape of it. Low latency, because WebTransport is designed to minimise latency, making it suitable for real-time applications such as gaming, video streaming and collaborative editing. Bidirectional communication, allowing simultaneous data exchange between client and server, enabling efficient back-and-forth communication without the need for multiple requests. Multiplexing, so multiple streams can be multiplexed over a single connection, reducing overhead and improving performance. Security, since WebTransport benefits from the security features provided by the web platform, including transport encryption and same-origin policy. And native browser support, which is the one that matters for the design of this library.

The security point is worth understanding as a platform property rather than a library property. The same-origin policy and the transport encryption come from the browser, which means a WebTransport client in a page is subject to the same rules a fetch is, and a server cannot simply accept any origin.

The two things the README flags are the same two things any WebTransport implementation has to say. WebTransport is still a draft and not yet standardised, and the WTransport library, while functional, is not considered completely production-ready. It should be used with caution and may undergo changes as the WebTransport specification evolves.

That is the honest framing, and it is the single most important fact for an evaluator.

The API, and why the server side is four awaits long

The simple API section shows a server and a client side by side, and the server example is the one worth reading closely because the length is the design.

#[tokio::main]
async fn main() -> Result<()> {
    let config = ServerConfig::builder()
        .with_bind_default(4433)
        .with_identity(&identity)
        .build();

    let connection = Endpoint::server(config)?
        .accept()
        .await     // Awaits connection
        .await?    // Awaits session request
        .accept()  // Accepts request
        .await?;   // Awaits ready session

    let stream = connection.accept_bi().await?;
    // ...
}

Those four awaits are the protocol showing through the API. There is a connection, then a session request, then the server has to accept the request, then the session is ready. A WebSocket handshake is one round trip and then you have a stream. A WebTransport session is a QUIC-level connection with a WebTransport handshake layered on top, and each of those steps is a place where the connection can fail, and each one is a separate await.

The rest of the server example is one call. connection.accept_bi() awaits a bidirectional stream, and from there you have a readable and a writable half.

The client is much shorter:

#[tokio::main]
async fn main() -> Result<()> {
    let config = ClientConfig::default();

    let connection = Endpoint::client(config)?
        .connect("https://[::1]:4433")
        .await?;

    let stream = connection.open_bi().await?.await?;
    // ...
}

Note the double await on open_bi. Opening a stream is itself a request, so the first await gets the stream handle and the second waits for it to be ready, and the same shape as the server's accept chain appears here in compressed form.

The ServerConfig is built with a builder that sets the bind address and an identity, and the identity is the TLS certificate. The default bind is port 4433, which is a non-standard port chosen to avoid needing a privileged one for the example.

Everything is built on tokio, and every API is async. The crate is designed to be async-friendly rather than async-only, but the examples make the intended style clear.

The browser on the other end, which is the point of the whole thing

The browser integration section is the part that distinguishes this from a Rust library that talks to another Rust library, and it is short.

WebTransport is supported in modern browsers, enhancing the capabilities of web applications. The example creates a native browser WebTransport client connecting to a Rust server, with JavaScript that does the whole thing in a dozen lines.

// Create a WebTransport instance connecting to the Rust server
let transport = new WebTransport('https://[::1]:4433');
await transport.ready;

// Create a bidirectional stream
let stream = await transport.createBidirectionalStream();

// Send data from the client to the server
await stream.writable.getWriter().write(new TextEncoder().encode("hello"));

// Read data reply from the server
let data = await stream.readable.getReader().read();
console.log(data);

The API shape is worth noting. There is no callback and no event handler; the browser side is promise-based, and await transport.ready is the equivalent of the server's ready session await. A stream has a writable and a readable, you get a writer from the writable and a reader from the readable, and both are streams in the WHATWG sense, so they compose with the rest of the platform's stream machinery.

That is the real argument for WebTransport over WebSocket, and it is worth stating: the browser gets a stream, not a message event, so back-pressure and partial reads work the way the platform already does elsewhere.

The example also connects to https://[::1]:4433, the IPv6 loopback in bracket notation, which is what a QUIC or HTTP/3 client needs since the address family is not negotiable the way it is for TCP.

The README points at the W3C WebTransport API documentation for the full browser capabilities.

Running the example, and the workspace behind the crate

Getting started is a clone and a cargo run, and the example is designed to be end to end.

git clone https://github.com/BiagioFesta/wtransport.git

The examples/full.rs is a minimal but complete server example that demonstrates the usage of WebTransport, and you run it with:

cargo run --example full

This example initiates an echo WebTransport server that can receive messages, and it also includes an integrated HTTP server. That last detail is what makes the example work in a browser, because the same port has to serve both the WebTransport endpoint and the page that talks to it.

The instructions are to open a supported web browser at http://127.0.0.1:8080, so the integrated HTTP server serves a page that connects back over WebTransport to the same process.

The repository layout shows a Cargo workspace with two members, wtransport and wtransport-proto, on resolver 2, which is the structure of a library plus its generated protocol code. There is a clippy.toml at the root and a pre-commit configuration.

The workspace lints are the interesting part of the Cargo.toml, because they encode the project's stance on unsafe code and on lint hygiene. unfulfilled_lint_expectations is denied, so a lint you said you expected cannot silently stop firing. unit_bindings is denied. unsafe_op_in_unsafe_fn is denied, which is the lint that forces explicit unsafe blocks inside unsafe functions, and it is a deny rather than a warn, which is a meaningful signal in a crate that does protocol parsing. unused_qualifications is a warning. On the clippy side, manual_is_variant_and and manual_let_else are warnings, and unnecessary_cast is denied.

The licence situation is worth noting for a library that others embed: there are two licence files at the root, LICENSE-APACHE and LICENSE-MIT, the standard Rust pairing of the customary dual licence of the Rust ecosystem, and the project itself is Apache-2.0.

The release cadence, the draft dependency, and what a version number means here

The maintenance picture is the one that has to factor into any adoption decision, because the protocol underneath is still moving.

The release list shows 0.7.2 from 2026-08-11, 0.7.1 from 2026-04-26 and 0.7.0 from 2026-02-08, so three releases in six months with a patch, a minor and a minor, and the last push to the repository was on 2026-09-28 with the repository not archived. That is an actively worked-on crate, and the 0.7 line rather than a 1.0 line is itself a signal about how settled the API is.

The reason is in the notes, and it is not a self-deprecating aside. WebTransport is still a draft and not yet standardised, and the library may undergo changes as the specification evolves. That is a category of risk different from an ordinary dependency: a library can break because its author changed a function signature, or it can break because the protocol it implements gained a field that changes the wire format. A WebTransport implementation has to follow the second kind of change, and the specification is identified by a draft number, draft-ietf-webtrans-http3, which is what the README links to.

There are also bindings for other languages, with the Elixir binding wtransport-elixir listed as the example. That is a useful signal about how portable the implementation is across stacks, and it also means the protocol is being implemented more than once, which is generally a good sign for a draft becoming stable.

The documentation lives on docs.rs with a crate badge pointing there, and there is a Discord channel for chat. The README rounds off with a pointer to the W3C WebTransport API documentation for the browser side of the story, which is where you would look for the full capabilities on the client.

So the honest summary is that this is a well-built crate with strict lint policy sitting on top of a specification that is still in flight, and the sensible way to use it is to pin a version, test against the browsers you care about, and expect to revisit as the draft moves.

Editorial conclusion

Adopt wtransport if you are writing a Rust service that has to serve a browser over a low latency bidirectional connection, because the browser-to-Rust path is the case the library demonstrates and the HTTP/3 stack it builds on is the reason WebTransport exists. Do not adopt it expecting a stable protocol, since the project states plainly that WebTransport is still a draft and that the library is not considered completely production-ready. Before you build on it, read the notes section, check whether the draft version the library tracks has moved, and plan for the API to change as the specification evolves.

Frequently asked questions

Official sources

1. BiagioFesta/wtransport on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases