# WebTransport Day (webtransport.day): full content > An independent resource for web developers building realtime apps: WebTransport, the web platform and AI coding tools. WebTransport Day is an independent resource for web developers building realtime apps: WebTransport and the web platform, plus hands-on coverage of the AI coding tools developers use to build them. It is not affiliated with the public echo server that previously ran on this domain. This domain previously hosted a public WebTransport echo server. That service is no longer running here. This site is now an independent developer resource and is not affiliated with the original service. Contains 14 documents. Most recent content update: 2026-10-31. Curated index: https://webtransport.day/llms.txt --- # Public WebTransport echo servers: history, status and alternatives Source: https://webtransport.day/echo-server/ Published: 2026-10-28 Updated: 2026-10-31 Facts checked: 2026-10-28 > What a WebTransport echo server is, what happened to the public one on webtransport.day, and a checked list of other public and open-source test servers. Notice: This domain previously hosted a public WebTransport echo server. That service is no longer running here. This site is now an independent developer resource and is not affiliated with the original service. Short answer: A WebTransport echo server accepts a WebTransport session and returns the data a client sends on streams and datagrams. The public one that ran on webtransport.day is no longer running here. Other public servers exist, but their operators control availability and origin rules, so test with the browser tester or run one locally. ## Key facts - **Old service:** No longer running on this domain - **First seen:** Announced in July 2022 on the Chromium web-transport-dev group - **Old homepage:** Archived by the Wayback Machine from 14 July 2022 to 11 May 2026 - **Documented alternatives:** W3C sample hosts and echo.semantic-ui.com - **Reachability:** Not tested from this site; check with the tester ## What is a WebTransport echo server? A WebTransport echo server is a small server that accepts a WebTransport session and sends back what the client sent. It is the "hello world" test target for the protocol. If an echo round trip works, DNS, UDP reachability, QUIC, HTTP/3, the certificate, the origin check and your client code all work. Because WebTransport offers two kinds of delivery, a useful echo server returns both: - **Stream data.** The client opens a bidirectional stream, writes bytes, and the server writes the same bytes back on that stream. - **Datagrams.** The client sends an unreliable datagram and the server sends one back. Datagrams are not retransmitted ([RFC 9221](https://www.rfc-editor.org/rfc/rfc9221)), so a reply can be lost. ## How does an echo server work? A browser opens a connection with `new WebTransport(url)`, as defined by the [W3C WebTransport specification](https://www.w3.org/TR/webtransport/) and documented on [MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API). The URL must use `https`, and the server must speak HTTP/3 over QUIC (UDP) using the session setup in the [IETF WebTransport over HTTP/3 draft](https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/), which is still a draft. The server accepts the session, then reads from the streams and datagrams the client opens and writes data back. The [what is WebTransport](/guides/what-is-webtransport/) guide explains the handshake; the [WebTransport tester](/tools/webtransport-tester/) shows the round trip in a browser. ## What was the public echo server on webtransport.day? The domain previously hosted a free public WebTransport echo server. It was announced in July 2022 in a thread titled "A public WebTransport Echo Server" on the [Chromium web-transport-dev group](https://groups.google.com/a/chromium.org/g/web-transport-dev/c/z_42BDxK5Dg), as a way for web developers to try WebTransport from the browser without deploying a server of their own. That thread is the original announcement and we credit it as such. We say nothing about the people behind the service beyond what the thread says. What the sources show, in order: - **July 2022.** The announcement thread above. The Wayback Machine has a [copy of the homepage from 14 July 2022](https://web.archive.org/web/20220714034209/https://webtransport.day/), the earliest we found. - **2022 to 2026.** The homepage was a browser test page. [An archived copy from 28 March 2023](https://web.archive.org/web/20230328195025/https://webtransport.day/) and [one from 10 May 2025](https://web.archive.org/web/20250510022024/https://webtransport.day/) show it described as a tool to connect to an arbitrary WebTransport server, with the endpoint `https://echo.webtransport.day`. - **Documentation links.** Chrome for Developers states that "a community-maintained echo server is available at webtransport.day" on its [WebTransport page](https://developer.chrome.com/docs/capabilities/web-apis/webtransport). The Rust `yew-webtransport` demo describes itself as a port of the site's client page. - **A second test page.** An [archived copy of `/serverless` from 8 February 2023](https://web.archive.org/web/20230208093159/https://webtransport.day/serverless) shows a different test page, pointed at `https://usa.echo.webtransport.day/serverless`. See [what that URL holds now](/serverless/#history-of-this-url). - **June and July 2025.** In the same Chromium thread, a user reported that `echo.webtransport.day` returned `ERR_NAME_NOT_RESOLVED`, and a reply in July 2025 said the site no longer worked. - **May 2026.** The Wayback Machine holds a [copy of the homepage dated 11 May 2026](https://web.archive.org/web/20260511121505/https://webtransport.day/). The homepage copy therefore stayed online after those reports that the echo endpoint had stopped answering. We do not know why. The Chrome documentation page still linked to the domain when we opened it on 2026-10-30. > **Known unknowns:** We do not know the exact date the echo endpoint stopped answering, or the full list of regional hostnames it used. The sources above name `echo.webtransport.day` and `usa.echo.webtransport.day`. We also cannot test QUIC from this site's build, so the servers listed below are documented, not confirmed reachable. ## Which public WebTransport echo servers exist now? We list a server only if we found documentation for it and opened that documentation on 2026-10-28. We cannot open QUIC connections from this site's build, so "documented" never means "reachable right now". Test any of them with the [browser tester](/tools/webtransport-tester/). Whether a server accepts connections from this site's origin is up to its operator. | Server | WebTransport endpoint | What it does | Source and notes | |---|---|---|---| | W3C WebTransport samples, Chicago | `wt-ord.akaleapi.net/echo/` (client page) | Echo sample from the W3C WebTransport repository, with a browser client | Listed in the [W3C repository README](https://github.com/w3c/webtransport/blob/main/README.md). The page answered over HTTPS on 2026-10-28; the QUIC endpoint was not tested. Operator not stated. | | W3C WebTransport samples, Amsterdam | `wt-ams.akaleapi.net/echo/` (client page) | Same sample, second location | Same source and caveats. The page notes it needs a recent Chromium. | | echo.semantic-ui.com | `https://echo.semantic-ui.com/echo` | Echoes datagrams and streams, with a test client | Run by Jack Lukic per its page. Stated limits: 1 MiB and 120 seconds per session, 4 sessions per address. Source is [MIT-licensed](https://github.com/jlukic/semantic-echo). | [Try echo.semantic-ui.com in the tester](/tools/webtransport-tester/?url=https%3A%2F%2Fecho.semantic-ui.com%2Fecho). The link only fills in the URL; you still press Connect. ### Servers you run yourself If you need something dependable, run an echo server you control: | Project | Language | What the README or source shows | |---|---|---| | [W3C samples: echo](https://github.com/w3c/webtransport/tree/main/samples/echo) | Python server, JS client | The same sample the hosted servers above run. | | [aioquic](https://github.com/aiortc/aioquic) | Python | `examples/demo.py` has a WebTransport echo at `/wt` for datagrams and stream data. The server targets an older draft, so check it against your browser. | | [wtransport](https://github.com/BiagioFesta/wtransport) | Rust | The `full` example is a server and browser page, but it replies `ACK` instead of echoing the bytes. | | [webtransport-go](https://github.com/quic-go/webtransport-go) | Go | Runnable client and server in `example/`. Its README does not say whether it echoes. | | [Chrome samples](https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport) | Python (aioquic) | The server is not an echo: it answers on `/counter` with a count of the bytes received. | See [test WebTransport locally](/guides/test-webtransport-locally/) for steps and the [client libraries](/guides/webtransport-client-libraries/) guide for current release information. ### What about Media over QUIC relays? Media over QUIC (MoQ) relays are public WebTransport endpoints in some cases, but they are media relays, not echo servers. A connection to one proves the transport works, but you will not get your bytes back. Cloudflare's MoQ relays, for example, are created through its dashboard and use tokens, so they are not open test endpoints. ## Why can't this site run the echo server again? This site is static HTML served from Cloudflare's network. A WebTransport server needs to accept QUIC connections on a UDP port and keep long-lived HTTP/3 sessions open. A static file host and an HTTP proxy do not do that, so nothing on this domain can answer a WebTransport handshake. The [serverless and edge](/serverless/) page explains what each platform documents about running WebTransport. That is why the old echo hostnames redirect to this page, and why the browser tester is a client for servers you choose rather than a replacement server. ## How do I know if a public echo server is up? Open the tester, paste the server's WebTransport URL, and press Connect. If the session opens, send a message on a stream and a datagram. If it fails, the [handshake debugging guide](/guides/debug-webtransport-handshake-errors/) lists the usual causes. Browsers deliberately report little about failures, so a failed connection is not proof that the server is down: it may only reject this page's origin. ### Is there still a free public WebTransport echo server? Yes, at least two are documented as of 2026-10-28: the W3C WebTransport samples hosts and echo.semantic-ui.com. We cannot test QUIC from this site, so availability is documented, not guaranteed. Paste the URL into the browser tester to check it from your own network. ### Why does a server that works in one browser fail in another? WebTransport is implemented in different browsers at different times, and servers target specific protocol draft versions. MDN lists Chrome 97, Firefox 114 and Safari 26.4 as the first versions with the API; a server built for an older draft may not work with newer clients. ### Can I use someone else's public echo server in production tests? Treat public echo servers as a convenience for manual checks. Their operators may rate-limit or remove them. For automated tests, run your own echo server locally or in CI. ## Sources - W3C: WebTransport specification: https://www.w3.org/TR/webtransport/ - MDN: WebTransport API: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API - IETF draft-ietf-webtrans-http3: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/ - RFC 9114: HTTP/3: https://www.rfc-editor.org/rfc/rfc9114 - Chromium web-transport-dev: "A public WebTransport Echo Server" (July 2022 announcement and later replies): https://groups.google.com/a/chromium.org/g/web-transport-dev/c/z_42BDxK5Dg - Chrome for Developers: How to use WebTransport: https://developer.chrome.com/docs/capabilities/web-apis/webtransport - Wayback Machine: webtransport.day homepage, earliest copy found (14 July 2022): https://web.archive.org/web/20220714034209/https://webtransport.day/ - Wayback Machine: webtransport.day homepage (28 March 2023): https://web.archive.org/web/20230328195025/https://webtransport.day/ - Wayback Machine: webtransport.day homepage (10 May 2025): https://web.archive.org/web/20250510022024/https://webtransport.day/ - Wayback Machine: webtransport.day homepage, latest copy found (11 May 2026): https://web.archive.org/web/20260511121505/https://webtransport.day/ - Wayback Machine: webtransport.day/serverless (8 February 2023): https://web.archive.org/web/20230208093159/https://webtransport.day/serverless - W3C WebTransport repository README (list of hosted samples): https://github.com/w3c/webtransport/blob/main/README.md - W3C WebTransport samples: echo (source): https://github.com/w3c/webtransport/tree/main/samples/echo - echo.semantic-ui.com: https://echo.semantic-ui.com/ - jlukic/semantic-echo (source, MIT): https://github.com/jlukic/semantic-echo - Google Chrome samples: WebTransport client and server: https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport - aioquic (examples/demo.py, http3_server.py): https://github.com/aiortc/aioquic - BiagioFesta/wtransport examples: https://github.com/BiagioFesta/wtransport - security-union/yew-webtransport: https://github.com/security-union/yew-webtransport --- # Debugging WebTransport handshake errors: a practical checklist Source: https://webtransport.day/guides/debug-webtransport-handshake-errors/ Published: 2026-10-28 Updated: 2026-10-28 Facts checked: 2026-10-28 > Why a WebTransport connection fails and what to check: certificates, serverCertificateHashes, HTTP/3 support, UDP, origin and path, per the spec. Short answer: A failed WebTransport handshake usually means an untrusted certificate, a server without HTTP/3 or WebTransport support, a wrong path, a rejected Origin, or UDP blocked on the network. Browsers expose little detail on purpose, so work through the checklist and test with a known-good server using the browser tester. ## Key facts - **Usual causes:** Certificate, HTTP/3 or WebTransport support, path or origin, UDP reachability - **Self-signed certificates:** Need serverCertificateHashes: ECDSA P-256 key, validity under two weeks - **Error detail:** Intentionally limited by browsers until the endpoint is verified as WebTransport ## Why does a WebTransport connection fail? A WebTransport session needs several things to line up before the first byte of your data moves: a reachable UDP port, a QUIC connection, a trusted certificate, an HTTP/3 server that supports WebTransport, a path it serves, and an `Origin` it accepts. If any one is wrong, the browser rejects the `ready` promise, and usually `closed` as well, with little explanation. ## What does the browser tell you? Two things are worth knowing before you start: - **Synchronous errors.** The `WebTransport` constructor throws `SyntaxError` for an invalid URL, a non-`https` scheme or a fragment in the URL, according to the specification and MDN. Check this before suspecting the network. - **Asynchronous failures.** On a network or establishment failure the specification moves the transport to a failed state and rejects `closed` and `ready` with a `WebTransportError` (its `source` is `session`). The specification also says the detailed reason is withheld until the endpoint has been verified as a WebTransport server, and certificate errors are fatal. So the message you see is intentionally unspecific. Message strings are not specified, so do not parse them. For reference, when we pointed the [tester](/tools/webtransport-tester/) at a closed port in a Chromium-based browser on 2026-10-28, it reported `WebTransportError: Opening handshake failed.` with source `session`; other browsers and versions may word it differently. When a connection that was working ends gracefully, `closed` resolves with a close code and reason instead. ## What should I check first? Work through these in order. Each item is a real constraint from the specification, the IETF draft or the QUIC and HTTP/3 RFCs. 1. **The URL.** Use `https://host:port/path`. WebTransport has no plain-text mode. 2. **UDP reachability.** WebTransport over HTTP/3 uses QUIC, which runs over UDP. If a firewall, security group or network filters UDP to that port, the session cannot establish. Browsers do not document this as a distinct error, so treat it as a practical cause to rule out, not something the error will state. 3. **HTTP/3 and WebTransport enabled on the server.** The draft requires the server to signal extended CONNECT support, HTTP Datagrams and the WebTransport setting, and to allow QUIC datagrams. If it does not, clients must not start a session. A server that only speaks HTTP/1.1 or HTTP/2 over TCP will not work. 4. **The path.** The server must accept WebTransport on the exact path in your URL. The draft suggests a 405 for an unsupported resource, and clients do not follow redirects for this request. 5. **The origin.** Browsers send an `Origin` header. A server may reject origins it does not trust (the draft suggests 403). Testing from a different origin than your app can hide or reveal this. 6. **The certificate.** See the next section. 7. **A proxy or CDN in between.** Several CDNs and load balancers terminate HTTP/3 at the edge or speak HTTP/1.1 to the origin. See [WebTransport and serverless](/serverless/). ## How do certificates work with WebTransport? A normal connection uses the Web PKI. The server's certificate must be valid for the hostname and chain to a trusted authority, as with any HTTPS site. For development you can instead supply `serverCertificateHashes`. According to the specification and MDN: - The option takes an array of objects with `algorithm: 'sha-256'` and a `value` holding the hash. - The hash is the SHA-256 of the DER-encoded leaf certificate. - The certificate must be X.509v3 and currently valid, and its **total validity must not exceed two weeks**. - The key algorithms an implementation accepts are implementation-defined but must include **ECDSA P-256** and must not include RSA. - Several hashes can be supplied, which allows rotation. - When hashes are used, they replace normal certificate validation for that connection, and the connection cannot be pooled. Generate a compliant certificate and its hash with OpenSSL (an example, adjust names to suit): ```sh openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \ -days 13 -subj "/CN=localhost" -addext "subjectAltName=DNS:localhost" \ -keyout key.pem -out cert.pem openssl x509 -in cert.pem -outform der | openssl dgst -sha256 ``` Paste the resulting hex into the optional field in the [WebTransport tester](/tools/webtransport-tester/). A 14-day certificate sits exactly at the limit, so we use 13 days to stay under it. ## How do I tell a server problem from a client problem? Isolate it: 1. Point the [tester](/tools/webtransport-tester/) at a server you do not control that is documented as an echo server (see the [echo server list](/echo-server/)). If it connects, your browser and network are fine. 2. Run your own server locally with a library example ([local testing guide](/guides/test-webtransport-locally/)) and connect with `serverCertificateHashes`. If that works, the problem is hosting, DNS, certificates or the network path. 3. Check the browser's developer tools network or QUIC logging for the failing connection, and the server's own logs for the request and its response status. 4. Test from a different network. If UDP is filtered on one network, it fails there only. ## What about older servers and draft versions? The IETF protocol document has been revised many times. Library READMEs say which draft they implement (for example `webtransport-go` states draft-16), and some older examples target earlier drafts. A mismatch can look like any other handshake failure. See [client and server libraries](/guides/webtransport-client-libraries/). ## Still stuck? Reduce the problem to the smallest case: one server, one URL, one browser, one echo message. The [tester](/tools/webtransport-tester/) prints the connection state and any error the browser provides, which is the information to include when you ask for help. ### Why is the error message so vague? The specification withholds the specific connection error until the endpoint is verified to be a WebTransport server, which prevents pages from using failed connections to probe networks. Expect an opaque failure: the transport's closed and ready promises reject. ### How do I use a self-signed certificate with WebTransport? Pass serverCertificateHashes when constructing WebTransport. The certificate must be X.509v3 with a validity period of at most two weeks, use an ECDSA P-256 key (RSA keys must not be accepted), and you supply the SHA-256 hash of its DER encoding. ### Does a 403 or 405 from the server show up in the browser? The draft recommends 403 for a rejected Origin and 405 for an unsupported resource, but the browser reports the failure through the transport promises rather than as an HTTP status you can read. ## Sources - W3C: WebTransport (connection errors, serverCertificateHashes): https://www.w3.org/TR/webtransport/ - MDN: WebTransport() constructor: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport - MDN: WebTransportError: https://developer.mozilla.org/en-US/docs/Web/API/WebTransportError - IETF draft-ietf-webtrans-http3: session establishment: https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/ - RFC 9114: HTTP/3: https://www.rfc-editor.org/rfc/rfc9114 - RFC 9000: QUIC: https://www.rfc-editor.org/rfc/rfc9000 --- # How to test WebTransport locally with an example server Source: https://webtransport.day/guides/test-webtransport-locally/ Published: 2026-10-28 Updated: 2026-10-28 Facts checked: 2026-10-28 > Run a local WebTransport server from the wtransport or webtransport-go examples, then connect from the browser, with a self-signed certificate hash. Short answer: To test WebTransport locally, run a library's example server, open the browser client it serves, and connect with the server's self-signed certificate hash through serverCertificateHashes. The Rust wtransport "full" example and the Go webtransport-go example both do this. Neither needs browser flags. Commands below follow each project's README. ## Key facts - **Rust example:** cargo run --example full (acknowledges with ACK, does not echo) - **Go example:** go run . in example/server (README does not say whether it echoes) - **Certificate:** ECDSA P-256, validity under two weeks, for serverCertificateHashes ## What do I need to test WebTransport locally? You need three things: a server that speaks WebTransport over HTTP/3, a certificate the browser will accept, and a client. The easiest path is to let a library's example generate a self-signed certificate and serve its own test page. The commands below come from each project's README and example source as of 2026-10-28. Treat them as examples and check the repository for current instructions. ## Option 1: Rust, the wtransport "full" example The [wtransport](https://github.com/BiagioFesta/wtransport) repository includes `client.rs`, `server.rs`, `full.rs` and `gencert.rs` in its examples. From a clone of the repository: ```sh cargo run --example full ``` According to the example's source, it: - starts an HTTP server on `127.0.0.1:8080` serving a test page, and a WebTransport server on an operating-system-assigned UDP port, - creates a self-signed identity for `localhost`, `127.0.0.1` and `::1`, and - injects the SHA-256 hash of that certificate into the page, which passes it as `serverCertificateHashes`. Open `http://127.0.0.1:8080`, press connect, and send something. The server acknowledges each stream and datagram with the text `ACK`; it does not echo your bytes back. ## Option 2: Go, the webtransport-go example The [webtransport-go](https://github.com/quic-go/webtransport-go) README says it implements draft-16, and its `example` directory has a server, a Go client and a browser client: ```sh cd example/server go run . ``` Per the example README, the server prints the certificate hash, serves a browser client at `http://localhost:6120`, and runs WebTransport at `https://localhost:6121/webtransport`. The certificate is a deterministically generated P-256 certificate that rotates weekly. Open the browser client with the hash pre-filled and press connect. The README does not say whether this server echoes data, so check its source if you need that. ## Option 3: a true echo server For a server that returns your bytes, use the W3C WebTransport samples echo server ([source](https://github.com/w3c/webtransport/tree/main/samples/echo)), or the Python `aioquic` examples, where `demo.py` echoes datagrams and stream data at `/wt`. The aioquic examples README gives the server command: ```sh python examples/http3_server.py --certificate cert.pem --private-key key.pem ``` Their echo endpoint is then `https://localhost:4433/wt`. That README accepts an older draft than current browsers may expect and mentions Chrome flags for self-signed certificates; we could not confirm interoperability with current browsers, so verify before relying on it. ## How do I use my own certificate? Generate an ECDSA P-256 certificate valid for less than two weeks and hash it, as described in [debugging handshake errors](/guides/debug-webtransport-handshake-errors/): ```sh openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \ -days 13 -subj "/CN=localhost" -addext "subjectAltName=DNS:localhost" \ -keyout key.pem -out cert.pem openssl x509 -in cert.pem -outform der | openssl dgst -sha256 ``` Start your server with `cert.pem` and `key.pem`, then paste the hash into the self-signed certificate field in the [WebTransport tester](/tools/webtransport-tester/) and connect to `https://localhost:/`. ## How do I test my own client code? Use the example server for the transport and write your client against it. A minimal browser client looks like this (an example, with a placeholder URL and hash handling left to you): ```js const hash = Uint8Array.from(/* 32 bytes of your certificate's SHA-256 */); const transport = new WebTransport('https://localhost:4433/echo', { serverCertificateHashes: [{ algorithm: 'sha-256', value: hash }], }); await transport.ready; console.log('connected'); transport.close(); ``` If the connection fails, work through the [handshake checklist](/guides/debug-webtransport-handshake-errors/). For library choices, see [WebTransport libraries](/guides/webtransport-client-libraries/). ### Why does the Rust example reply "ACK" instead of echoing my text? Its source acknowledges bidirectional streams and datagrams with the literal text ACK. It confirms that the whole path works but does not return your bytes. For a true echo, use the W3C samples echo server or the aioquic demo. ### Do I need Chrome flags to connect to localhost? Not with serverCertificateHashes: the example pages pass the hash, which tells the browser to trust that self-signed certificate. Older aioquic instructions mention flags such as --ignore-certificate-errors-spki-list; we could not confirm they are still required. ### Can I connect to my local server from the hosted tester? The hosted tester can connect to an https URL such as https://localhost:4433/ if your server allows this site's origin and you supply the certificate hash. Many example servers do not restrict origins, but check yours. ## Sources - BiagioFesta/wtransport: examples (client, server, full, gencert): https://github.com/BiagioFesta/wtransport - wtransport full example source: https://github.com/BiagioFesta/wtransport/blob/master/wtransport/examples/full.rs - quic-go/webtransport-go: example README: https://github.com/quic-go/webtransport-go/tree/master/example - aioquic examples README: https://github.com/aiortc/aioquic/blob/main/examples/README.rst - W3C WebTransport samples: echo: https://github.com/w3c/webtransport/tree/main/samples/echo - MDN: WebTransport() constructor (serverCertificateHashes): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport --- # WebTransport client and server libraries: what exists and its status Source: https://webtransport.day/guides/webtransport-client-libraries/ Published: 2026-10-28 Updated: 2026-10-28 Facts checked: 2026-10-28 > Verified WebTransport libraries for Rust, Go, Python, Node.js, .NET and Deno, with licence, latest release and the status caveats each project states. Short answer: Maintained WebTransport libraries exist for Rust (wtransport), Go (webtransport-go), Node.js (@fails-components/webtransport) and Python (aioquic, which targets an older draft). Browsers provide the client API natively. .NET and Deno have preview or experimental support. Each project states draft or production-readiness caveats, listed below as checked on 2026-10-28. ## Key facts - **Maintained options seen:** Rust (wtransport, web-transport-quinn), Go (webtransport-go), Node.js (@fails-components/webtransport) - **Draft caveat:** webtransport-go states it implements draft-16 - **Browsers:** The client API is built in; libraries are for servers, native clients and tests ## What WebTransport libraries exist? Browsers include the client API, so libraries matter mostly for servers, native clients and tests. The table lists libraries we confirmed exist, with the release information we read on the project's registry or GitHub API on 2026-10-28. Releases move quickly: check the linked page before you depend on a version. | Library | Language | Role | Licence | Latest release we saw | Stated caveats | |---|---|---|---|---|---| | [wtransport](https://github.com/BiagioFesta/wtransport) | Rust | Client and server | MIT or Apache-2.0 | 0.7.2 (2026-08-11) | README: WebTransport "is still a draft and not yet standardized"; not considered completely production-ready | | [web-transport-quinn](https://github.com/moq-dev/web-transport) | Rust, WASM | Client and server | Apache-2.0 or MIT | 0.13.5 (2026-10-24) | No explicit caveats found. Part of the moq-dev project | | [yew-webtransport](https://github.com/security-union/yew-webtransport) | Rust (WASM) | Browser client for Yew apps | MIT | 0.22.0 (2026-02-09) | Needs the `web_sys_unstable_apis` cfg flag; low activity | | [webtransport-go](https://github.com/quic-go/webtransport-go) | Go | Client and server | MIT | v0.13.0 (2026-08-30) | README: implements draft-16; pre-v1 | | [aioquic](https://github.com/aiortc/aioquic) | Python | Server (examples); client not verified | BSD-3-Clause | 1.7.0 | Example server accepts an older draft (draft02), so browser interop is unverified. The examples note the specifications are not finalised | | [@fails-components/webtransport](https://github.com/fails-components/webtransport) | Node.js | Client and server | BSD-3-Clause per npm (README says the wider FAILS project is AGPL v3: check before adopting) | 1.6.11 (2026-10-18) | Implements parts of the spec; HTTP/2 mode experimental; some API gaps | | ASP.NET Core Kestrel (`IHttpWebTransportFeature`) | C# | Server | Part of ASP.NET Core | n/a | Microsoft's API docs call WebTransport a preview feature that needs `EnablePreviewFeatures` | | Deno | TypeScript runtime | Built in (via `Deno.QuicEndpoint`) | n/a | n/a | Deno 2.2 described experimental support requiring `--unstable-net`; we could not confirm the current flag status | | [Google QUICHE](https://github.com/google/quiche) | C++ | Building blocks | BSD-3-Clause | none shown | A QUIC and HTTP/3 implementation with WebTransport code; embedders implement platform APIs | ### Notes on the table - **wtransport** is the most complete Rust option we found for both roles and has examples (`client`, `server`, `full`, `gencert`). - **webtransport-go** is built on quic-go. Its README says it implements draft-16 and its pkg.go.dev page marks it as pre-stable. - **aioquic** is a general QUIC and HTTP/3 library. Its main README does not mention WebTransport; the examples do. Test it against your target browsers before relying on it. - **@fails-components/webtransport** works through a native libquiche addon. Read its licensing statement before using it in a product. ## What about browsers? The API is built in. MDN lists Chrome 97, Firefox 114 and Safari 26.4 as first versions. See [what is WebTransport](/guides/what-is-webtransport/) for the full status. ## What did we leave out, and why? - **Node.js core.** No native WebTransport. A draft pull request (nodejs/node#63827) was open and unmerged on 2026-10-28. - **Java and Netty.** We found no Java WebTransport library. `netty-incubator-codec-http3`, an experimental HTTP/3 codec, was archived in May 2026 and does not mention WebTransport. - **Media over QUIC stacks** (such as `cloudflare/moq-rs` and `moq-dev/moq`). They use WebTransport but are not general WebTransport libraries. - **Chromium's `quic_transport`.** Its origin trial ended around 2021; we could not confirm any current status, so it is not listed. - **Unverified projects** seen only in search results. ## How do I pick one? 1. Choose by language and deployment target; see [WebTransport and serverless](/serverless/) for hosting constraints. 2. Check the draft version the library implements against the browsers you support. 3. Run its example server locally and connect with the [WebTransport tester](/tools/webtransport-tester/). The [local testing guide](/guides/test-webtransport-locally/) covers the steps. ### Which WebTransport server library should I start with? Pick the language you already deploy. Rust has wtransport and web-transport-quinn, Go has webtransport-go (stated to implement draft-16), and Node.js has @fails-components/webtransport. Check each project's stated draft version against the browsers you target. ### Is there a native WebTransport API in Node.js? Not in Node.js core as of 2026-10-28. A draft pull request (nodejs/node#63827) was open and unmerged when we checked. Use a library such as @fails-components/webtransport instead. ### Do I need a library on the client? No for browsers: WebTransport is a built-in API. Libraries are for servers, for native clients, and for non-browser environments or tests. ## Sources - MDN: WebTransport API: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API - wtransport (GitHub): https://github.com/BiagioFesta/wtransport - wtransport on crates.io: https://crates.io/crates/wtransport - yew-webtransport (GitHub): https://github.com/security-union/yew-webtransport - quic-go/webtransport-go (GitHub): https://github.com/quic-go/webtransport-go - webtransport-go on pkg.go.dev: https://pkg.go.dev/github.com/quic-go/webtransport-go - aioquic (GitHub): https://github.com/aiortc/aioquic - @fails-components/webtransport (GitHub): https://github.com/fails-components/webtransport - moq-dev/web-transport (GitHub): https://github.com/moq-dev/web-transport - ASP.NET Core: IHttpWebTransportFeature (Microsoft Learn): https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.features.ihttpwebtransportfeature - Deno 2.2 release notes: https://deno.com/blog/v2.2 - google/quiche (GitHub): https://github.com/google/quiche - Node.js pull request 63827 (WebTransport draft): https://github.com/nodejs/node/pull/63827 --- # WebTransport vs WebSocket (and WebRTC data channels): a sourced comparison Source: https://webtransport.day/guides/webtransport-vs-websocket/ Published: 2026-10-28 Updated: 2026-10-31 Facts checked: 2026-10-28 > WebTransport vs WebSocket compared on transport, head-of-line blocking, unreliable delivery and support, with notes on WebRTC data channels. Short answer: Choose WebSocket when you need a mature, widely supported, single ordered message stream. Consider WebTransport when you need several independent streams without head-of-line blocking, or unreliable datagrams for latency-sensitive data. WebTransport runs over HTTP/3 and QUIC, has less server tooling, and its protocol is still an IETF draft. ## Key facts - **WebSocket:** One reliable, ordered message channel (RFC 6455) - **WebTransport:** Many streams plus datagrams over one QUIC connection - **WebRTC data channels:** Peer-to-peer, not client-to-server - **Standards:** WebSocket is an RFC; WebTransport over HTTP/3 is still an IETF draft ## What is the short difference between WebTransport and WebSocket? WebSocket gives a page one reliable, ordered, bidirectional message channel over a single connection. WebTransport gives a page many independent reliable streams and optional unreliable datagrams over one HTTP/3 connection. The trade is flexibility against maturity. ## How do they compare side by side? | | WebSocket | WebTransport | |---|---|---| | Underlying transport | TCP (HTTP/1.1 upgrade; also specified over HTTP/2 and HTTP/3) | QUIC via HTTP/3 (an HTTP/2 binding is a separate draft) | | Data model | One ordered stream of messages | Many streams (uni- and bidirectional) plus datagrams | | Head-of-line blocking | A lost packet delays everything on the connection | Streams are independent: no ordering across streams in QUIC | | Unreliable delivery | Not available | Datagrams: no retransmission | | Connection setup | TCP handshake plus TLS | QUIC handshake, documented as faster than TCP plus TLS | | Browser API | `WebSocket` events | `WebTransport` with the Streams API, including backpressure | | Browser support | Universal | Chrome 97, Firefox 114, Safari 26.4 (MDN); Baseline 2026 | | Server ecosystem | Mature, everywhere | Smaller: see the [libraries guide](/guides/webtransport-client-libraries/) | | Standards status | RFC 6455 | W3C Candidate Recommendation; IETF protocol still a draft | | Runs on serverless platforms | Commonly documented | Not documented by the providers we checked: see [serverless](/serverless/) | Sources: MDN, Chrome for Developers, the W3C specification, RFC 9000, RFC 9221 and the IETF draft. The WebSocket protocol is RFC 6455; it can also be carried over HTTP/2 and HTTP/3 (RFC 9220 covers the latter). ## When does head-of-line blocking matter? Over TCP, a lost packet holds back all data behind it until retransmission, even if that data belongs to unrelated messages. This is called head-of-line blocking. With WebTransport, each stream is delivered independently, so a game that sends chat, state updates and file chunks on separate streams will not stall chat while a chunk is retransmitted. If your app sends one logical flow of small messages, you may never notice the difference. Try it yourself. This is a toy model with arbitrary ticks, not a benchmark: ## When do datagrams help? Datagrams are useful for data where a late packet is worse than a missing one: positional updates, voice or sensor samples. They are not retransmitted (RFC 9221) and may arrive out of order or not at all, but they are still congestion-controlled. The tester lets you send one and see whether your server answers: [WebTransport tester](/tools/webtransport-tester/). ## How does it compare with WebRTC data channels? WebRTC data channels are peer-to-peer. They use ICE for connectivity, DTLS for encryption and SCTP for delivery, and can be configured as reliable or unreliable. WebTransport is client-to-server only, built on HTTP/3, and typically simpler to deploy when you control the server. It is not a UDP socket API: you cannot send arbitrary UDP packets, only datagrams within a session. Neither MDN nor the Chrome documentation frames this as a replacement for WebRTC, and neither do we. ## What are the downsides of WebTransport? - **Server tooling.** Fewer libraries, and several state that they track a draft. See [client and server libraries](/guides/webtransport-client-libraries/). - **Infrastructure.** QUIC runs over UDP. Networks, load balancers and CDNs that handle only TCP or HTTP/1.1 to the origin will not carry it, and we found no serverless function platform that documents WebTransport server support. - **Standards risk.** The IETF protocol document is not an RFC yet, and servers written for older drafts can fail against current browsers. - **Debuggability.** Browsers reveal little about failed handshakes by design. Read [debugging handshake errors](/guides/debug-webtransport-handshake-errors/). ## Which should I pick? Use WebSocket if you need broad compatibility, simple infrastructure, or a single ordered channel. Use WebTransport if you have a measured need for independent streams or unreliable datagrams and can run a QUIC-capable server. Use WebRTC if the traffic is between peers. ## Which one should an AI assistant pick for you? Short answer: do not leave the protocol choice to the assistant. Make the choice from the rules in this guide, then put it in the prompt. 1. **Default to WebSocket** when the feature needs one ordered channel of messages, broad browser compatibility or simple infrastructure. 2. **Ask for WebTransport only for a measured need**: independent streams that must not block each other, or unreliable datagrams for data where a late packet is worse than a missing one. State which of the two it is. 3. **Ask for WebRTC data channels** when the traffic is between peers rather than between a browser and your server. 4. **Say where the server will run.** WebTransport needs a QUIC-capable server with a reachable UDP port, and we found no serverless function platform that documents WebTransport server support. See [WebTransport and serverless](/serverless/). 5. **Name the library and the protocol version** you want on the server side, because several libraries track an IETF draft. See [client and server libraries](/guides/webtransport-client-libraries/). If an assistant generates WebTransport code, check these before trusting it: the URL uses `https://`, the server speaks HTTP/3 over UDP, the certificate is trusted by the browser or the page passes `serverCertificateHashes` for a short-lived self-signed one, and the page does not assume that datagrams arrive in order or at all. You can run the generated client against a local server with [test WebTransport locally](/guides/test-webtransport-locally/) and the [WebTransport tester](/tools/webtransport-tester/). Our section on [AI coding tools for web and realtime developers](/ai-coding/) covers the tools themselves. If you are choosing a realtime platform rather than a protocol, a comparison of realtime services is planned under [realtime and messaging](/category/realtime-messaging/). ### Is WebTransport faster than WebSocket? It can avoid delays that WebSocket cannot: separate streams do not block each other, datagrams are not retransmitted, and QUIC connection setup is quicker than TCP plus TLS. We have not benchmarked either, and results depend on your network and server, so measure your own workload. ### Can WebTransport do peer-to-peer like WebRTC? No. WebTransport is client-to-server only. WebRTC data channels connect peers using ICE, DTLS and SCTP. If you need browser-to-browser traffic, WebTransport does not replace WebRTC. ### Should I migrate an existing WebSocket app? Only if you have a concrete problem WebSocket cannot solve, such as head-of-line blocking across logically separate flows or a need for unreliable delivery. Otherwise WebSocket remains the lower-risk choice. ## Sources - MDN: WebTransport API: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API - Chrome for Developers: How to use WebTransport: https://developer.chrome.com/docs/capabilities/web-apis/webtransport - W3C: WebTransport: https://www.w3.org/TR/webtransport/ - RFC 9000: QUIC: https://www.rfc-editor.org/rfc/rfc9000 - RFC 9221: QUIC datagram extension: https://www.rfc-editor.org/rfc/rfc9221 - IETF draft-ietf-webtrans-http3: https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/ - Can I use: WebTransport: https://caniuse.com/webtransport --- # What is WebTransport? Streams, datagrams, HTTP/3 and QUIC explained Source: https://webtransport.day/guides/what-is-webtransport/ Published: 2026-10-28 Updated: 2026-10-28 Facts checked: 2026-10-28 > WebTransport explained: one multiplexed HTTP/3 connection with reliable streams and unreliable datagrams. How it works, support and standards status. Short answer: WebTransport is a browser API and protocol framework for opening one secure, multiplexed connection to a server, today over HTTP/3, and sending data on many independent reliable streams plus unreliable datagrams. It is built on QUIC. Browsers expose it as the WebTransport class, available only in secure contexts. ## Key facts - **Protocol:** WebTransport over HTTP/3 (IETF draft-ietf-webtrans-http3, draft-16 when checked) - **Transport:** QUIC, over UDP - **W3C status:** Candidate Recommendation Snapshot, 30 July 2026 - **Browser support:** Chrome 97, Firefox 114, Safari 26.4 (MDN); Edge follows Chromium - **Requires:** A secure context (HTTPS) ## What is WebTransport? WebTransport lets a web page or app open one secure connection to a server and then send and receive data on many independent streams, plus unreliable datagrams, over that one connection. In browsers it appears as the `WebTransport` JavaScript class. Servers speak it over HTTP/3, which runs on QUIC, which runs on UDP. Think of it as a general-purpose, client-to-server transport that sits between WebSocket (one ordered, reliable stream) and raw UDP (unreliable packets, but no browser access). ## How does a WebTransport connection start? The browser first establishes a QUIC connection and an HTTP/3 session with the server. It then sends an HTTP/3 extended CONNECT request to the URL you gave. If the server answers with a 2xx status, the request stream becomes a WebTransport session, and both sides can open streams and send datagrams that belong to it. Some details from the IETF draft that explain common failures: - The server must signal support through HTTP/3 settings (extended CONNECT and HTTP Datagrams, plus the WebTransport setting) and allow QUIC datagrams. If it does not, clients must not start a session. - Browsers include an `Origin` header, and a server can reject unwanted origins (the draft suggests a 403 response). - A server can reject a path it does not serve (405 is suggested), and clients do not follow redirects (3xx) for this request. The [handshake debugging guide](/guides/debug-webtransport-handshake-errors/) turns these into a checklist. ## What are streams and datagrams? A WebTransport session carries three kinds of data flow: - **Bidirectional streams.** Either side can send and receive. Bytes arrive reliably and in order within the stream. This is the closest match to a WebSocket message flow. - **Unidirectional streams.** One side sends, the other receives. Useful for one-shot messages or server push. - **Datagrams.** Small, unreliable, unordered messages. QUIC datagrams are not retransmitted when lost (RFC 9221), though they are still congestion-controlled. Streams are independent: QUIC does not impose ordering across streams (RFC 9000), so a lost packet delaying one stream does not block the others. That property is the main reason people compare it favourably with a single TCP connection. In the browser, streams use the standard Streams API (`ReadableStream`, `WritableStream`), including backpressure. ## What does the API look like? This is a minimal client example. The URL is a placeholder, not a live server: ```js // Example only: replace the URL with a server you control. const transport = new WebTransport('https://example.com:4433/echo'); await transport.ready; const stream = await transport.createBidirectionalStream(); const writer = stream.writable.getWriter(); await writer.write(new TextEncoder().encode('hello')); await writer.close(); const reader = stream.readable.getReader(); const { value } = await reader.read(); console.log(new TextDecoder().decode(value)); transport.close(); ``` `transport.ready` resolves when the session is established; `transport.closed` settles when it ends. The URL must use `https`. You can try this against a server of your choice with the [WebTransport tester](/tools/webtransport-tester/). ## What states does a WebTransport session go through? The W3C specification defines five internal session states: connecting, connected, draining, closed and failed. They are not exposed as a public `state` attribute; you observe them through the `ready`, `closed` and `draining` promises. A session starts in connecting. It becomes connected when `ready` resolves, and it can fail if setup fails or the network breaks. When the server asks for a graceful wind-down the session is draining, which still works but should be wrapped up soon. ## What is the standards status of WebTransport? Status as checked on 28 October 2026; the standards documents change, so see the linked sources for the current state. - **W3C API:** Candidate Recommendation Snapshot dated 30 July 2026, with a newer Editor's Draft maintained on GitHub. - **IETF protocol:** WebTransport over HTTP/3 is draft-ietf-webtrans-http3 (draft-16, dated 6 July 2026, when we checked). It is in working-group last call and is not yet an RFC. The related overview draft has the same status. - **Building blocks that are RFCs:** QUIC (RFC 9000), HTTP/3 (RFC 9114), QUIC datagrams (RFC 9221) and HTTP datagrams (RFC 9297). Because the protocol draft has changed over time, a server written for an older draft may not interoperate with a current browser. Check which draft your library implements; the [libraries guide](/guides/webtransport-client-libraries/) records what each project states. ## Which browsers support WebTransport? As checked on 28 October 2026, MDN labels the API Baseline 2026 "newly available", meaning it works across the latest browser versions since March 2026. Its compatibility data lists these first versions: | Browser | First version with the API (per MDN) | |---|---| | Chrome | 97 | | Firefox | 114 | | Safari | 26.4 | | Edge | follows Chromium (caniuse: 98) | Some options have narrower support, for example `serverCertificateHashes` (Chrome 100, Firefox 125, Safari 26.4 per MDN data) and the `congestionControl` option (limited availability). The API requires a secure context and is available in Web Workers. Always feature-detect with `'WebTransport' in window`. ## How is it different from WebSocket and WebRTC? WebSocket gives you one reliable, ordered message stream per connection. WebRTC data channels are peer-to-peer and need ICE, DTLS and SCTP. WebTransport is client-to-server, supports multiple streams and datagrams, and has a simpler server story on top of HTTP/3. See [WebTransport vs WebSocket](/guides/webtransport-vs-websocket/) for a sourced comparison. ## How do I try it? Open the [WebTransport tester](/tools/webtransport-tester/) and connect to an echo server. Find one on the [echo server page](/echo-server/), or [run one locally](/guides/test-webtransport-locally/). ### Is WebTransport a standard yet? The W3C WebTransport API is a Candidate Recommendation Snapshot (30 July 2026). WebTransport over HTTP/3 is still an IETF Internet-Draft (draft-ietf-webtrans-http3-16 when checked), not an RFC. ### Which browsers support WebTransport? MDN lists Chrome 97, Firefox 114 and Safari 26.4 as the first versions with the API, and marks it Baseline 2026, newly available since March 2026. caniuse reports Edge 98 and later. ### Does WebTransport replace WebSocket? Not as a drop-in. It offers multiple streams and datagrams and avoids cross-stream head-of-line blocking, but WebSocket has a more mature server ecosystem and broader compatibility. See the comparison guide. ### Can WebTransport run over HTTP/2? An HTTP/2 binding is specified in a separate IETF draft for fallback, but the transport the API is best known for is HTTP/3 over QUIC. A client can set requireUnreliable to forbid a fallback that cannot send unreliable datagrams. ## Sources - W3C: WebTransport (Candidate Recommendation Snapshot, 30 July 2026): https://www.w3.org/TR/webtransport/ - MDN: WebTransport API: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API - MDN: WebTransport interface: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport - Chrome for Developers: How to use WebTransport: https://developer.chrome.com/docs/capabilities/web-apis/webtransport - IETF draft-ietf-webtrans-http3: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/ - IETF draft-ietf-webtrans-overview: https://datatracker.ietf.org/doc/draft-ietf-webtrans-overview/ - RFC 9000: QUIC: https://www.rfc-editor.org/rfc/rfc9000 - RFC 9114: HTTP/3: https://www.rfc-editor.org/rfc/rfc9114 - RFC 9221: An Unreliable Datagram Extension to QUIC: https://www.rfc-editor.org/rfc/rfc9221 - RFC 9297: HTTP Datagrams and the Capsule Protocol: https://www.rfc-editor.org/rfc/rfc9297 - Can I use: WebTransport: https://caniuse.com/webtransport --- # WebTransport and serverless or edge platforms: what is possible Source: https://webtransport.day/serverless/ Published: 2026-10-28 Updated: 2026-10-31 Facts checked: 2026-10-28 > Can serverless or edge platforms act as a WebTransport server? What Cloudflare, AWS, Google Cloud, Vercel, Fastly and others document, checked 2026-10-28. Notice: This domain previously hosted a public WebTransport echo server. That service is no longer running here. This site is now an independent developer resource and is not affiliated with the original service. Short answer: We found no official documentation from Cloudflare, AWS, Google Cloud, Vercel, Fastly, Azure, Deno or Akamai saying their serverless or edge function layer can act as a WebTransport server. Documented routes are a server you run on a host with open UDP, or managed Media over QUIC relays. Checked 2026-10-28. ## Key facts - **Providers checked:** Cloudflare, AWS, Google Cloud, Azure, Vercel, Fastly, Deno, Fly.io, Akamai - **Result:** No provider documents a function layer acting as a WebTransport server - **Documented route:** A server you run on a host with an open UDP port ## Can a serverless or edge platform run a WebTransport server? As of 2026-10-28, we found no provider documentation that says its serverless or edge function layer can act as a WebTransport server. That is a statement about documentation, not a proof that it cannot work. The routes that providers do document are running your own QUIC-capable server on a host with a reachable UDP port, and managed Media over QUIC (MoQ) relays on some networks. ## Why is WebTransport a poor fit for request/response functions? A WebTransport session is a long-lived connection. A browser opens it with an HTTP/3 extended CONNECT request, and the session then carries many streams and datagrams over one QUIC connection. The IETF's WebTransport over HTTP/3 draft is still a draft (draft-16 as we checked), and it requires the server to send specific HTTP/3 settings before clients may start a session. Serverless platforms are built around short invocations that return a response. Their documentation reflects that: - AWS Lambda describes itself as short-lived compute with a 15-minute maximum. - Vercel and Google Cloud Run document WebSockets, but close them when the function or request timeout is reached and tell you to reconnect and keep state elsewhere. - Several CDNs terminate HTTP/3 only between the user and the edge. CloudFront and Azure Front Door document HTTP/1.1 to the origin, and Fastly and Cloudflare document that HTTP/3 to the origin is not supported. That is a fact about those products; connecting it to WebTransport is our inference, not a vendor statement. > **Known unknowns:** "Not documented" is not "unsupported". We could not confirm whether Cloudflare's MoQ relays use WebTransport or raw QUIC, we found nothing in Netlify's documentation either way, and some provider pages blocked automated reading. Check each provider's current documentation before deciding. ## What do providers document today? Verdicts describe what we could find in official documentation on 2026-10-28. "Not documented" is not "unsupported". | Platform | What the docs say | WebTransport server | |---|---|---| | [Cloudflare Workers](https://developers.cloudflare.com/workers/runtime-apis/) | WebSockets (server and client), outbound TCP sockets, inbound HTTP/3 to the edge. Inbound TCP is listed as coming soon. | Not documented. No WebTransport or UDP in the runtime API list. | | [Cloudflare proxy and Spectrum](https://developers.cloudflare.com/spectrum/reference/limitations/) | HTTP/3 from clients to Cloudflare. Docs state HTTP/3 to origin is not yet supported. Spectrum proxies TCP and UDP (Enterprise for custom apps). | Not documented for QUIC or WebTransport. | | [Cloudflare MoQ relays](https://developers.cloudflare.com/moq/) | Managed relays in beta, created in the dashboard, token-gated. | Media relays, not a general WebTransport server. The docs we read do not say whether WebTransport or raw QUIC is used. | | [Fastly Compute](https://www.fastly.com/documentation/guides/full-site-delivery/performance/enabling-http3-for-fastly-services/) | HTTP/3 on the user side; WebSocket passthrough. HTTP/3 to origin unsupported. | Not documented. | | [Vercel Functions](https://vercel.com/docs/functions/websockets) | WebSockets, pinned to an instance and closed at the maximum duration. | Not documented. | | [AWS CloudFront, API Gateway, Lambda](https://aws.amazon.com/blogs/aws/new-http-3-support-for-amazon-cloudfront/) | HTTP/3 for viewers; WebSocket over HTTP/1.1; WebSocket APIs with a 2-hour maximum. | Not documented. | | [AWS Network Load Balancer](https://aws.amazon.com/about-aws/whats-new/2025/11/aws-network-load-balancer-quic-passthrough-mode/) | QUIC passthrough listeners (announced 2025-11-13), connection-ID stickiness, QUIC v1 only. | A load balancer, not a server: you run the WebTransport server behind it. AWS makes no WebTransport statement. | | [Google Cloud](https://docs.cloud.google.com/load-balancing/docs/features) | HTTP/3 from clients to some load balancers; Cloud Run supports WebSockets. Passthrough network load balancers handle TCP and UDP. | Not documented for Cloud Run. Self-host behind a passthrough load balancer. | | [Azure Front Door](https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq) | HTTP and HTTP/2 to clients; HTTP/1.1 to origin. | Not documented. | | [Deno Deploy](https://docs.deno.com/deploy/) | Apps, frameworks, caching and cron. | Not documented. The Deno runtime has an unstable QUIC API, which is a different thing from Deploy. | | [Fly.io](https://docs.fly.io/networking/udp-and-tcp) | UDP services on a dedicated IPv4 address; you bind to a specific address and keep packets near 1,300 bytes. | No official WebTransport statement. It supplies UDP; the server is yours. | | [Akamai](https://techdocs.akamai.com/property-mgr/docs/http3-support) | HTTP/3 from clients to the edge. | Not documented. | ## What works in practice? The documented building blocks are all variations on "run the server yourself": 1. **A VM, bare-metal host or container host with an open UDP port.** You need a reachable UDP port and a certificate your clients trust. The moq.dev production guide also suggests a TCP port for HTTPS or WebSocket fallback and raising Linux UDP buffer sizes. 2. **Fly.io UDP services**, within its documented constraints on addresses and packet size. 3. **A UDP- or QUIC-passthrough load balancer** such as AWS NLB or a Google Cloud passthrough network load balancer, in front of servers you run. QUIC connection IDs let a connection survive address changes, so load balancers need connection-ID-aware routing; AWS documents connection-ID stickiness for this. 4. **Managed MoQ relays** if your real goal is media distribution rather than a generic WebTransport server. For libraries to run on those hosts, see [WebTransport client and server libraries](/guides/webtransport-client-libraries/). ## What does this mean for this site? This site is static HTML on Cloudflare Workers static assets. It cannot answer a WebTransport handshake, and an HTTP proxy in front of a domain does not turn it into a QUIC echo service. That is why [the old echo hostnames redirect to the echo server page](/echo-server/) and why the [browser tester](/tools/webtransport-tester/) connects to servers you choose rather than to one of ours. ## History of this URL This path previously held a WebTransport test page for a third-party serverless service; an [archived copy from February 2023](https://web.archive.org/web/20230208093159/https://webtransport.day/serverless) shows it. That service is not available here, and nothing on this site connects to it. ## How was this checked? We opened each provider's own documentation, changelog or announcement on 2026-10-28 and recorded what it says. Some pages blocked automated fetching or returned errors; we did not work around that, and we left those claims out. Netlify's documentation did not mention WebSockets, HTTP/3 or WebTransport in the pages we reached, so it is not in the table. If you know of an official statement that corrects this page, [contact us](/contact/). ### Can Cloudflare Workers be a WebTransport server? Cloudflare's Workers documentation lists WebSockets and outbound TCP sockets, but we found no WebTransport or UDP server API in its runtime or protocol pages on 2026-10-28. Cloudflare does document HTTP/3 from clients to its edge, and managed Media over QUIC relays in beta. ### Does "not documented" mean "impossible"? No. It means we could not find a provider statement that it works. Platforms change, and a feature may exist in a changelog or preview we did not find. Check the provider's current documentation before you decide. ### What is the simplest way to host a WebTransport server? Run a WebTransport-capable server on a virtual machine or container host that exposes a UDP port, with a trusted certificate. Fly.io documents UDP services, and AWS and Google Cloud offer load balancers that pass UDP or QUIC traffic through. ## Sources - Cloudflare Workers: runtime APIs: https://developers.cloudflare.com/workers/runtime-apis/ - Cloudflare Workers: supported protocols: https://developers.cloudflare.com/workers/reference/protocols/ - Cloudflare: HTTP/3 (Speed): https://developers.cloudflare.com/speed/optimization/protocol/http3/ - Cloudflare Spectrum limitations: https://developers.cloudflare.com/spectrum/reference/limitations/ - Cloudflare Media over QUIC (MoQ): https://developers.cloudflare.com/moq/ - IETF draft-ietf-webtrans-http3 (WebTransport over HTTP/3): https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/ - Fastly: enabling HTTP/3: https://www.fastly.com/documentation/guides/full-site-delivery/performance/enabling-http3-for-fastly-services/ - Vercel: functions and WebSockets: https://vercel.com/docs/functions/websockets - AWS: HTTP/3 support for Amazon CloudFront: https://aws.amazon.com/blogs/aws/new-http-3-support-for-amazon-cloudfront/ - AWS: Network Load Balancer QUIC passthrough mode: https://aws.amazon.com/about-aws/whats-new/2025/11/aws-network-load-balancer-quic-passthrough-mode/ - AWS Lambda limits: https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html - Google Cloud load balancing features: https://docs.cloud.google.com/load-balancing/docs/features - Google Cloud Run container contract: https://docs.cloud.google.com/run/docs/container-contract - Azure Front Door FAQ: https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq - Deno Deploy documentation: https://docs.deno.com/deploy/ - Fly.io: UDP and TCP services: https://docs.fly.io/networking/udp-and-tcp - Akamai: HTTP/3 support in Property Manager: https://techdocs.akamai.com/property-mgr/docs/http3-support - moq.dev: production setup: https://doc.moq.dev/setup/prod - Wayback Machine: webtransport.day/serverless (8 February 2023): https://web.archive.org/web/20230208093159/https://webtransport.day/serverless --- # WebTransport server-readiness checklist Source: https://webtransport.day/tools/server-checklist/ Published: 2026-10-28 Updated: 2026-10-28 Facts checked: 2026-10-28 > Interactive checklist for a WebTransport server: UDP, HTTP/3, certificates, settings, CONNECT, origin, firewall. Copy a what-to-check-next report. Short answer: A WebTransport server needs seven things in place: a reachable UDP port, HTTP/3 over QUIC, a certificate the browser accepts, the WebTransport settings enabled, extended CONNECT handling at the right path, an origin policy that allows your page, and a firewall that passes UDP. Tick what is done and copy a report of what to check next. ## How do I use the checklist? Work through the items from top to bottom, tick each one you have confirmed on the server you are testing, and copy the report of unchecked items. The order follows the path a connection takes: network first, then QUIC and TLS, then HTTP/3 and WebTransport, then policy. If you tick everything and the connection still fails, test with the [WebTransport tester](/tools/webtransport-tester/) and read [debugging handshake errors](/guides/debug-webtransport-handshake-errors/). ## What does each item mean? Each item states what to verify and why, with the source it comes from. Names such as the HTTP/3 settings are defined by the IETF draft, which can change. ### Does this checklist test my server? No. It cannot open QUIC connections to your server for you; it is a checklist you complete by hand, and it produces a copyable list of what to check next. To test a connection from your browser, use the WebTransport tester. ### Why are some setting names marked draft-specific? WebTransport over HTTP/3 is still an IETF draft, and the names of some HTTP/3 settings are defined by that draft. They may change before it becomes an RFC, so check the draft your server library implements. ### Does my page need to be on the same origin as the server? No. Browsers send an Origin header, and the server decides which origins to accept. A server that rejects your page origin is a common cause of failed connections. ## Sources - W3C: WebTransport: https://www.w3.org/TR/webtransport/ - IETF draft-ietf-webtrans-http3: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/ - RFC 9114: HTTP/3: https://www.rfc-editor.org/rfc/rfc9114 - RFC 9000: QUIC: https://www.rfc-editor.org/rfc/rfc9000 - RFC 9221: An Unreliable Datagram Extension to QUIC: https://www.rfc-editor.org/rfc/rfc9221 - MDN: WebTransport() constructor (serverCertificateHashes): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport --- # WebTransport tester: connect and echo from your browser Source: https://webtransport.day/tools/webtransport-tester/ Published: 2026-10-28 Updated: 2026-10-28 Facts checked: 2026-10-28 > Free browser-based WebTransport tester. Connect to a WebTransport URL, send text on a stream or as a datagram, and see the echoed reply and errors. Short answer: The WebTransport tester is a free, client-side tool. Your browser connects directly to the WebTransport URL you enter, sends text over a bidirectional stream or as a datagram, and shows the reply, connection state and errors. Nothing passes through this site; the target server must support WebTransport and accept this page as an origin. ## What this tool does This page uses the browser's built-in `WebTransport` API. You enter a URL such as `https://example.com:4433/echo`, press **Connect**, and the browser opens a WebTransport session to that server. You can then send a text message on a new bidirectional stream, or as an unreliable datagram, and watch the reply arrive in the log. It is a client only. It does not run a server, it cannot make a server that is down respond, and it is not the old public echo service that used to live on this domain. To find a server to point it at, see the [list of public echo servers](/echo-server/) or run one yourself with the [local testing guide](/guides/test-webtransport-locally/). ## Requirements for the server - It must implement WebTransport over HTTP/3 and be reachable over UDP on the port in your URL. - The URL must use `https://`; WebTransport has no plain-text mode. - The server must accept a request whose `Origin` header is this site's origin. A server may reject other origins. - It needs a certificate your browser trusts, or a self-signed certificate that satisfies the `serverCertificateHashes` rules described above. - It must send a reply for the tester to display. Echo servers do; servers that only count bytes will show nothing. ## How do I use it? 1. Enter a `https://` URL for a WebTransport endpoint, including the port and path your server uses, for example `https://example.com:4433/echo` (a placeholder, not a live server). 2. If the server uses a self-signed certificate, open the optional section and paste the SHA-256 hash of its certificate. 3. Press **Connect**. The page reports `connecting`, then `connected` or `failed`. 4. Type a message, then send it on a bidirectional stream or as a datagram. Replies and errors appear in the log. 5. Press **Disconnect** when you finish. ## What does it check? - **Browser support.** It feature-detects the `WebTransport` class and shows a clear message if it is missing. - **URL validity.** It rejects non-`https` URLs and URLs with a fragment before opening a connection, as the specification requires. - **Session establishment.** It reports whether the browser could open a session and shows the error the browser returns. - **Echo behaviour.** It shows whatever the server sends back on a stream or as a datagram. ## What are its limits? - **Browser support.** The API must exist in your browser. MDN lists Chrome 97, Firefox 114 and Safari 26.4 as the first versions; options such as `serverCertificateHashes` arrived in some browsers later. - **Secure context.** WebTransport only works on HTTPS pages (or localhost), which this site is. - **Certificates.** A normal connection needs a certificate your browser trusts. A self-signed one works only through `serverCertificateHashes`: ECDSA P-256 key, total validity under two weeks. - **HTTP/3.** The server must speak HTTP/3 over QUIC and be reachable over UDP. The tester cannot tell you why a handshake failed; browsers withhold that detail on purpose. - **One message per stream.** Each stream send opens a new bidirectional stream and writes one message. It is not a load-testing or benchmarking tool. ## Privacy The tester sends nothing to this site. Your URL, messages and replies stay in the page and are discarded when you close it. There is no analytics on payloads. ## If the connection fails Read [debugging WebTransport handshake errors](/guides/debug-webtransport-handshake-errors/). Browsers report very little detail for a failed handshake by design, so the checklist matters more than the error text. ### Does the tester send my data to your servers? No. The page runs entirely in your browser and opens a connection only to the URL you type. The messages you send and the replies you receive are not transmitted to this site and no analytics are collected on them. ### Which servers can I test? Any server that speaks WebTransport over HTTP/3, is reachable over UDP from your network, and accepts requests whose Origin is this site. That usually means a server you run yourself, or a public test server whose operator allows cross-origin use. See the echo server list for self-hosted and public options. ### Why does my connection fail with no detailed error? Browsers deliberately limit how much they reveal about a failed WebTransport handshake until the endpoint is confirmed to be a WebTransport server. The debugging guide lists the usual causes: untrusted certificate, no HTTP/3 or WebTransport support on the server, wrong path, rejected origin, or blocked UDP. ### Can I test a server with a self-signed certificate? Yes, if the certificate meets the serverCertificateHashes rules: an ECDSA P-256 key and a total validity of less than two weeks. Paste the SHA-256 hash of the DER-encoded certificate into the optional hash field; the browser then trusts that certificate for the connection. ## Sources - MDN: WebTransport API: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API - MDN: WebTransport() constructor (serverCertificateHashes): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport - W3C: WebTransport specification: https://www.w3.org/TR/webtransport/ --- # WebTransport glossary Source: https://webtransport.day/glossary/ Checked: 2026-10-28 ## 0-RTT A QUIC and TLS 1.3 feature that lets a returning client send application data in its very first flight, before the handshake finishes, by reusing parameters from an earlier connection. That early data can be replayed by an attacker. Because of replay risk, clients should only send 0-RTT data when the application explicitly asks for it, and it should never trigger actions with unwanted side effects. Sources: RFC 9001: Using TLS to Secure QUIC: https://www.rfc-editor.org/rfc/rfc9001.html; RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3: https://www.rfc-editor.org/rfc/rfc8446.html ## ALPN A TLS extension that lets client and server agree, during the handshake, on which application protocol will run over the encrypted connection. HTTP/3 is identified by the ALPN token "h3". The client sends its protocols in preference order and the server picks exactly one. If none match, the server aborts with the fatal no_application_protocol alert. Sources: RFC 7301: TLS Application-Layer Protocol Negotiation Extension: https://www.rfc-editor.org/rfc/rfc7301.html; RFC 9114: HTTP/3: https://www.rfc-editor.org/rfc/rfc9114.html ## Backpressure A signal that flows backward through a chain of streams, telling the producer to slow down because the consumer cannot keep up. In the Streams API it is expressed through a queue's desiredSize. desiredSize is the high water mark minus the size of queued chunks. MDN notes the WebSocket API has no way to apply backpressure, which is one reason stream-based APIs such as WebTransport are attractive. Sources: Streams Standard (WHATWG): https://streams.spec.whatwg.org/; Streams API concepts (MDN): https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Concepts; WebSocket (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebSocket ## Bidirectional stream An ordered, reliable byte channel in which both endpoints can send data. In the browser, WebTransport exposes one as a WebTransportBidirectionalStream with a readable side for incoming bytes and a writable side for outgoing bytes. Either side can open one: call createBidirectionalStream() to open it, or read incomingBidirectionalStreams for those the server opens. Sources: WebTransportBidirectionalStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportBidirectionalStream; draft-ietf-webtrans-overview-13: The WebTransport Protocol Framework: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview; RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport: https://www.rfc-editor.org/rfc/rfc9000.html ## Capsule A type-length-value message defined by the HTTP Capsule Protocol and carried inside the data stream of an upgraded HTTP request, such as an Extended CONNECT. Receivers silently skip capsule types they do not recognise. The DATAGRAM capsule (type 0x00) carries an HTTP Datagram when QUIC DATAGRAM frames are unavailable. The WebTransport over HTTP/3 draft defines its own capsules, including WT_CLOSE_SESSION and WT_DRAIN_SESSION. Sources: RFC 9297: HTTP Datagrams and the Capsule Protocol: https://www.rfc-editor.org/rfc/rfc9297.html; draft-ietf-webtrans-http3-16: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16 ## closeInfo / close codes The dictionary passed to WebTransport.close(), holding a numeric closeCode (default 0) and a reason string. The closed promise later reports the same pair once the session ends. The spec truncates the UTF-8 encoded reason to 1024 bytes, and the HTTP/3 draft likewise caps the close message at 1024 bytes. An abrupt failure rejects the closed promise instead of resolving it. Sources: WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/; WebTransport.close() (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/close; WebTransport.closed (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/closed; draft-ietf-webtrans-http3-16: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16 ## Congestion control The sender-side logic that limits how much unacknowledged data is in flight so a connection adapts to network capacity instead of overwhelming it. QUIC defaults to a NewReno-style controller but permits others, such as CUBIC. QUIC datagrams are subject to the connection's congestion controller too: the sender must either delay a datagram until allowed or drop it. Sources: RFC 9002: QUIC Loss Detection and Congestion Control: https://www.rfc-editor.org/rfc/rfc9002.html; RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport: https://www.rfc-editor.org/rfc/rfc9000.html; RFC 9221: An Unreliable Datagram Extension to QUIC: https://www.rfc-editor.org/rfc/rfc9221.html ## congestionControl option A WebTransport constructor option that hints whether the browser should tune its congestion control for throughput or low latency. Accepted values are "default", "throughput" and "low-latency"; the browser may ignore the hint. The chosen preference can be read back from the congestionControl property. The spec flags "low-latency" as a feature at risk because no browser implements a low-latency algorithm yet. Sources: WebTransport() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport; WebTransport.congestionControl (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/congestionControl; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## Connection ID An identifier carried in QUIC packets that names a connection independently of IP addresses and ports, so packets still reach the right endpoint when the network path changes, such as moving from Wi-Fi to mobile data. Each endpoint chooses the connection IDs its peer will use to address it. Sources: RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport: https://www.rfc-editor.org/rfc/rfc9000.html; WebTransport API (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API ## Datagram A small, self-contained message sent without delivery or ordering guarantees. WebTransport datagrams travel in QUIC DATAGRAM frames, are never retransmitted, and are limited in size, yet remain subject to congestion control. Receivers may drop them, and QUIC gives them no explicit flow control. In the API, use datagrams.readable to receive and datagrams.createWritable() to send; datagrams.maxDatagramSize gives the largest allowed payload. Sources: RFC 9221: An Unreliable Datagram Extension to QUIC: https://www.rfc-editor.org/rfc/rfc9221.html; draft-ietf-webtrans-overview-13: The WebTransport Protocol Framework: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview; WebTransport.datagrams (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/datagrams; WebTransportDatagramDuplexStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportDatagramDuplexStream ## Draining A WebTransport session state entered when the server asks to gracefully wind the session down. The draining promise fulfills at that point; the session keeps working, but the application should finish up and move to a new session. In the W3C spec, [[State]] can be connecting, connected, draining, closed or failed. At the protocol level the HTTP/3 draft signals draining with a WT_DRAIN_SESSION capsule or an HTTP/3 GOAWAY. Sources: WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/; WebTransport.draining (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/draining; draft-ietf-webtrans-http3-16: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16 ## Extended CONNECT A variant of the HTTP CONNECT method that adds a :protocol pseudo-header naming the protocol to run over the stream. WebTransport sessions are created by sending an Extended CONNECT request over HTTP/3. A server must opt in with the SETTINGS_ENABLE_CONNECT_PROTOCOL setting (identifier 0x08 in HTTP/3). The mechanism was first defined for HTTP/2 and carried over to HTTP/3. Sources: RFC 8441: Bootstrapping WebSockets with HTTP/2: https://www.rfc-editor.org/rfc/rfc8441.html; RFC 9220: Bootstrapping WebSockets with HTTP/3: https://www.rfc-editor.org/rfc/rfc9220.html; draft-ietf-webtrans-http3-16: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16 ## Flow control Limits set by a receiver to stop a sender from transmitting more data than the receiver can buffer. QUIC applies them per stream and for the whole connection, using MAX_STREAM_DATA and MAX_DATA frames. Senders must never exceed either limit. QUIC datagrams are exempt from explicit flow control signaling. Sources: RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport: https://www.rfc-editor.org/rfc/rfc9000.html; RFC 9221: An Unreliable Datagram Extension to QUIC: https://www.rfc-editor.org/rfc/rfc9221.html ## GOAWAY An HTTP/3 frame that starts a graceful shutdown of a connection. After receiving it, a client cannot begin new WebTransport sessions on that connection and must open a fresh one. The WebTransport over HTTP/3 draft also treats it as a signal that applications should wind down their sessions on that connection. Sources: RFC 9114: HTTP/3: https://www.rfc-editor.org/rfc/rfc9114.html; draft-ietf-webtrans-http3-16: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16 ## Head-of-line blocking A stall in which one lost or delayed packet holds up unrelated data queued behind it. Over HTTP/2 on TCP a single loss stalls every request, whereas independent QUIC streams let other streams keep progressing. Sources: RFC 9114: HTTP/3: https://www.rfc-editor.org/rfc/rfc9114.html; WebTransport API (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API ## HTTP Datagrams A convention for sending multiplexed, possibly unreliable datagrams tied to an HTTP request. Over HTTP/3 they ride in QUIC DATAGRAM frames; where those are unavailable, the DATAGRAM capsule carries them. Each HTTP/3 datagram begins with a Quarter Stream ID, and endpoints must exchange SETTINGS_H3_DATAGRAM before sending any. The RFC says the feature is meant for HTTP extensions, not applications directly. Sources: RFC 9297: HTTP Datagrams and the Capsule Protocol: https://www.rfc-editor.org/rfc/rfc9297.html; draft-ietf-webtrans-http3-16: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16 ## HTTP/3 The mapping of HTTP onto QUIC instead of TCP. It relies on QUIC for stream multiplexing, per-stream flow control, loss recovery and encryption, and it is the transport that WebTransport sessions are carried over. Clients identify it with the ALPN token "h3" or discover it through the Alt-Svc mechanism. Sources: RFC 9114: HTTP/3: https://www.rfc-editor.org/rfc/rfc9114.html; draft-ietf-webtrans-http3-16: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16 ## Origin header An HTTP request header naming the web origin of the page making the request. Browsers send it when opening a WebTransport session, so servers can accept or reject connections based on which site initiated them. The WebTransport over HTTP/3 draft says browser clients must send it and that a server whose origin check fails replies with 403. Sources: WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/; draft-ietf-webtrans-http3-16: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16 ## QUIC A secure, multiplexed transport protocol that runs over UDP. It offers many independent flow-controlled streams, built-in TLS 1.3 encryption and connection IDs, and it underpins both HTTP/3 and WebTransport. QUIC packets are carried in UDP datagrams, and RFC 9002 supplies its loss detection and congestion control. Sources: RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport: https://www.rfc-editor.org/rfc/rfc9000.html; RFC 9001: Using TLS to Secure QUIC: https://www.rfc-editor.org/rfc/rfc9001.html; RFC 9002: QUIC Loss Detection and Congestion Control: https://www.rfc-editor.org/rfc/rfc9002.html ## ReadableStream A Streams API object representing a source of data that you consume chunk by chunk. WebTransport exposes incoming datagrams, incoming streams and received bytes as ReadableStreams, read with getReader() or for await. Reading a locked stream throws a TypeError, and breaking out of a for await loop cancels the stream by default. Received WebTransport data arrives as Uint8Array chunks. Sources: Streams Standard (WHATWG): https://streams.spec.whatwg.org/; ReadableStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream; WebTransport.incomingUnidirectionalStreams (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/incomingUnidirectionalStreams ## requireUnreliable A WebTransport constructor option, false by default, that forbids falling back to a reliable-only transport such as HTTP/2. When true, the session must be established over HTTP/3, which is what makes datagrams available. After ready, the reliability property reports "reliable-only" or "supports-unreliable", and the static WebTransport.supportsReliableOnly tells you whether the browser can fall back at all. Sources: WebTransport() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport; WebTransport.supportsReliableOnly (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/supportsReliableOnly_static; WebTransport.reliability (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/reliability; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## Secure context A browser environment judged sufficiently authenticated and confidential, typically an https page or localhost, in which powerful APIs are exposed. WebTransport is marked SecureContext, so it is unavailable on plain http pages. Check window.isSecureContext, or self.isSecureContext in a worker. Dedicated workers are secure only if their owner is. Sources: Secure contexts (MDN): https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Secure_Contexts; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/; WebTransport (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport ## sendOrder An integer option or property on WebTransport streams and datagram writables that sets relative send priority. Among streams that have a value, queued bytes on those with a higher value are sent first. Without a value, ordering depends on the implementation. The W3C spec also offers sendGroup to prioritise a set of streams together. Sources: WebTransport.createBidirectionalStream() (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/createBidirectionalStream; WebTransport.createUnidirectionalStream() (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/createUnidirectionalStream; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## serverCertificateHashes A WebTransport constructor option that lets a page trust a server certificate by its SHA-256 hash instead of relying on Web PKI validation. It is meant for short-lived, self-managed certificates and works only on dedicated connections. MDN says the certificate must be X.509v3 with under two weeks of validity and an ECDSA P-256 key, not RSA. Combining it with allowPooling: true is rejected. Sources: WebTransport() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## SETTINGS An HTTP/3 frame that each endpoint sends first on its control stream, announcing connection-wide parameters as identifier and value pairs. WebTransport servers use it to announce support, including Extended CONNECT and HTTP Datagrams. Draft 16 of the WebTransport over HTTP/3 spec names SETTINGS_WT_ENABLED, SETTINGS_ENABLE_CONNECT_PROTOCOL and SETTINGS_H3_DATAGRAM for this purpose. Sources: RFC 9114: HTTP/3: https://www.rfc-editor.org/rfc/rfc9114.html; draft-ietf-webtrans-http3-16: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16 ## Stream An ordered, reliable sequence of bytes of any length inside a QUIC connection. Many streams share one connection and are delivered independently, so one stalled stream does not block the rest. Streams are either unidirectional or bidirectional; the two low bits of a QUIC stream ID encode which type it is. Sources: RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport: https://www.rfc-editor.org/rfc/rfc9000.html; draft-ietf-webtrans-overview-13: The WebTransport Protocol Framework: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview ## TLS 1.3 The current version of Transport Layer Security, providing encryption, integrity and authentication with a one-round-trip handshake. QUIC requires TLS 1.3, so WebTransport over HTTP/3 is always encrypted. In QUIC the TLS handshake messages are carried in CRYPTO frames rather than TLS records, and endpoints must not negotiate anything older than TLS 1.3. Sources: RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3: https://www.rfc-editor.org/rfc/rfc8446.html; RFC 9001: Using TLS to Secure QUIC: https://www.rfc-editor.org/rfc/rfc9001.html; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## UDP A minimal Internet transport protocol that sends independent datagrams with no guarantee of delivery, ordering or duplicate protection. QUIC packets travel inside UDP datagrams, so networks that block UDP can break HTTP/3 and WebTransport. Sources: RFC 768: User Datagram Protocol: https://www.rfc-editor.org/rfc/rfc768.html; RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport: https://www.rfc-editor.org/rfc/rfc9000.html; WebTransport.supportsReliableOnly (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/supportsReliableOnly_static ## Unidirectional stream A one-way, ordered, reliable byte stream where only the endpoint that opened it can send. In the browser, ones you open are WebTransportSendStreams and ones the server opens arrive as WebTransportReceiveStreams. Open one with createUnidirectionalStream(); receive server-opened ones from incomingUnidirectionalStreams. Sources: WebTransport.createUnidirectionalStream() (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/createUnidirectionalStream; WebTransport.incomingUnidirectionalStreams (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/incomingUnidirectionalStreams; draft-ietf-webtrans-overview-13: The WebTransport Protocol Framework: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview ## WebRTC data channel A channel on an RTCPeerConnection for sending arbitrary data, primarily between peers. It can be configured ordered or unordered and with limited retransmits, whereas WebTransport connects a client to a server over HTTP/3. MDN describes it as carried over SCTP and DTLS, and notes the theoretical limit of 65,534 channels per peer connection. Sources: RTCDataChannel (MDN): https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel; WebTransport (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport ## WebSocket A TCP-based protocol that starts with an HTTP Upgrade handshake and then exchanges framed text or binary messages over one connection. Unlike WebTransport it has no independent streams or datagrams, and its browser API has no backpressure. It uses ws and wss URL schemes, and browsers send an Origin header so servers can reject unwanted origins. Sources: RFC 6455: The WebSocket Protocol: https://www.rfc-editor.org/rfc/rfc6455.html; WebSocket (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebSocket ## WebTransport A web API and protocol framework for client-server communication over HTTP/3, giving one connection many independent reliable streams plus unreliable datagrams. It is a more flexible alternative to WebSocket for latency-sensitive apps. The browser API is a W3C specification; the wire protocol is defined by IETF drafts that are still in progress. Sources: WebTransport (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/; draft-ietf-webtrans-overview-13: The WebTransport Protocol Framework: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview; draft-ietf-webtrans-http3-16: WebTransport over HTTP/3: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16 ## WebTransport session A single communication context between a WebTransport client and server. It groups the streams and datagrams exchanged between them and is created by an HTTP/3 request, and it ends when closed. A session may own a dedicated connection or share one with other sessions when pooling is allowed; sessions on a shared connection are logically independent. Sources: draft-ietf-webtrans-overview-13: The WebTransport Protocol Framework: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/; WebTransport() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport ## WebTransportError The error type produced by WebTransport operations. It extends DOMException and adds a source, either "stream" or "session", plus an optional streamErrorCode that the application can set when aborting a stream. Constructing a bad URL throws a plain SyntaxError instead, so check instanceof WebTransportError before reading these fields. Sources: WebTransportError (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportError; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## WritableStream A Streams API object representing a destination you write chunks to, with built-in queuing and backpressure. WebTransport uses WritableStreams for outgoing bytes and datagrams, written through getWriter(). Calling abort() puts the stream in an error state and discards queued writes. On a WebTransport send stream, abort can carry an application error code. Sources: Streams Standard (WHATWG): https://streams.spec.whatwg.org/; WritableStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WritableStream; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ --- # WebTransport API cheat sheet Source: https://webtransport.day/cheatsheet/ Checked: 2026-10-28 ## Create a session ### Connect with the WebTransport constructor The URL must use https and an explicit port; a bad URL or a fragment throws SyntaxError. MDN currently marks this 'Baseline 2026, Newly available' (since March 2026), with a note that parts of the feature have varying support, and it is secure-context only. ```js const transport = new WebTransport("https://example.com:4433/echo"); await transport.ready; // resolves once the session is established console.log("connected"); ``` Sources: WebTransport() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport; WebTransport.ready (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/ready; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Trust a certificate by hash with serverCertificateHashes Replaces Web PKI validation for this connection. MDN says the certificate must be X.509v3 with under two weeks of validity and an ECDSA P-256 key, and the option cannot be combined with allowPooling: true. Only sha-256 is defined. ```js const certHash = new Uint8Array(32); // placeholder: SHA-256 of your server certificate const transport = new WebTransport("https://example.com:4433/echo", { serverCertificateHashes: [{ algorithm: "sha-256", value: certHash }], }); await transport.ready; ``` Sources: WebTransport() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Hint a congestion control preference Only a hint; the browser may fall back to "default". MDN currently marks this 'Limited availability' (not Baseline) on the congestionControl property page, and the spec flags "low-latency" as a feature at risk because no browser implements a low-latency algorithm yet. ```js const transport = new WebTransport("https://example.com:4433/echo", { congestionControl: "low-latency", // "default" | "throughput" | "low-latency" }); await transport.ready; console.log(transport.congestionControl); // the preference as the browser reports it ``` Sources: WebTransport() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport; WebTransport.congestionControl (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/congestionControl; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Refuse a reliable-only fallback with requireUnreliable Defaults to false. MDN marks the reliability property page 'Limited availability' (not Baseline), while the constructor page shows 'Baseline 2026, Newly available' (since March 2026). ```js const transport = new WebTransport("https://example.com:4433/echo", { requireUnreliable: true, // do not fall back to a reliable-only (HTTP/2) session }); await transport.ready; console.log(transport.reliability); // "pending" before ready, then "reliable-only" or "supports-unreliable" ``` Sources: WebTransport() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport; WebTransport.reliability (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/reliability; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Negotiate an application protocol with protocols If the server supports none of the offered protocols, ready rejects. Per the spec, duplicates, empty values and values over 512 characters throw SyntaxError. The option is documented by both MDN and the W3C spec. ```js const transport = new WebTransport("https://example.com:4433/echo", { protocols: ["chat", "file-transfer"], // in order of preference }); await transport.ready; console.log(transport.protocol); // the server's choice, or "" if it selected none ``` Sources: WebTransport() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/WebTransport; WebTransport API (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## Session lifecycle ### Watch ready and closed Both promises exist from construction. closed resolves with { closeCode, reason } and rejects on unexpected closure such as a network failure. MDN currently marks this 'Baseline 2026, Newly available' (since March 2026). ```js const transport = new WebTransport("https://example.com:4433/echo"); transport.closed .then(({ closeCode, reason }) => console.log("closed", closeCode, reason)) .catch((err) => console.error("closed abruptly", err)); try { await transport.ready; } catch (err) { console.error("session failed", err); } ``` Sources: WebTransport.ready (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/ready; WebTransport.closed (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/closed; WebTransport API (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API ### React to draining Draining is only a request: either side may keep using the session, but the app is expected to wrap up soon. The W3C spec lists draining as a session state. MDN's draining page carries no Baseline banner at the moment. ```js async function migrateOnDraining(url, oldTransport) { await oldTransport.draining; // fulfills when the server signals draining const next = new WebTransport(url); await next.ready; oldTransport.close(); // retire the old session once the new one is up return next; } ``` Sources: WebTransport.draining (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/draining; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Close with a code and reason closeCode defaults to 0 and the reason is truncated to 1024 UTF-8 bytes per the spec. MDN names the parameter info; the spec calls it closeInfo. MDN currently marks this 'Baseline 2026, Newly available' (since March 2026). ```js transport.close({ closeCode: 17, reason: "CloseButtonPressed" }); const info = await transport.closed; console.log(info.closeCode, info.reason); ``` Sources: WebTransport.close() (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/close; WebTransport.closed (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/closed; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Inspect reliability after ready Tells you whether the session can carry unreliable datagrams. MDN currently marks this 'Limited availability' (not Baseline). ```js await transport.ready; // reliability is "pending" before this point if (transport.reliability === "reliable-only") { // no datagrams: stick to streams } else { // "supports-unreliable": datagrams are available } ``` Sources: WebTransport.reliability (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/reliability; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## Bidirectional streams ### Open a stream, write, then read Assumes a server that echoes and closes its side. MDN currently marks this 'Baseline 2026, Newly available' (since March 2026) for createBidirectionalStream(), with partial-support asterisk. It rejects with InvalidStateError if the session is closed or failed. ```js const stream = await transport.createBidirectionalStream(); const writer = stream.writable.getWriter(); await writer.write(new TextEncoder().encode("hello")); await writer.close(); // tries to send pending data before closing const reader = stream.readable.getReader(); for (;;) { const { value, done } = await reader.read(); if (done) break; console.log(new TextDecoder().decode(value)); // value is a Uint8Array } ``` Sources: WebTransport.createBidirectionalStream() (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/createBidirectionalStream; WebTransportBidirectionalStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportBidirectionalStream; WebTransport API (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API ### Accept server-opened streams incomingBidirectionalStreams is a ReadableStream of WebTransportBidirectionalStream objects. MDN currently marks this 'Baseline 2026, Newly available' (since March 2026). ```js const reader = transport.incomingBidirectionalStreams.getReader(); for (;;) { const { value: stream, done } = await reader.read(); if (done) break; // each value is a WebTransportBidirectionalStream opened by the server stream.readable.pipeTo(stream.writable).catch(console.error); // echo it back } ``` Sources: WebTransport.incomingBidirectionalStreams (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/incomingBidirectionalStreams; WebTransportBidirectionalStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportBidirectionalStream; ReadableStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream ### Prioritise streams with sendOrder MDN's createBidirectionalStream() page documents only sendOrder (an integer; its own examples pass a string). The W3C spec also lists sendGroup and waitUntilAvailable, which MDN does not describe on that page. ```js const urgent = await transport.createBidirectionalStream({ sendOrder: 10 }); const bulk = await transport.createBidirectionalStream({ sendOrder: 1 }); // queued bytes on the higher sendOrder stream are sent first ``` Sources: WebTransport.createBidirectionalStream() (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/createBidirectionalStream; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## Unidirectional streams ### Send on a client-opened stream The returned WebTransportSendStream is itself a WritableStream. MDN currently marks this 'Limited availability' (not Baseline) on the createUnidirectionalStream() page (it is also marked this way on the WebTransportSendStream page). ```js const stream = await transport.createUnidirectionalStream(); // a WebTransportSendStream const writer = stream.getWriter(); writer.write(new Uint8Array([65, 66, 67])); try { await writer.close(); // tries to send all pending data first console.log("All data has been sent."); } catch (error) { console.error(`An error occurred: ${error}`); } ``` Sources: WebTransport.createUnidirectionalStream() (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/createUnidirectionalStream; WebTransportSendStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportSendStream ### Receive server-opened unidirectional streams The outer loop awaits each stream in turn; handle streams concurrently in real code. MDN currently marks this 'Baseline 2026, Newly available' (since March 2026) for incomingUnidirectionalStreams, whereas the WebTransportReceiveStream page is marked 'Limited availability' (not Baseline). ```js const reader = transport.incomingUnidirectionalStreams.getReader(); for (;;) { const { value: receiveStream, done } = await reader.read(); if (done) break; const chunks = receiveStream.getReader(); // a WebTransportReceiveStream for (;;) { const r = await chunks.read(); if (r.done) break; console.log(r.value); // Uint8Array } } ``` Sources: WebTransport.incomingUnidirectionalStreams (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/incomingUnidirectionalStreams; WebTransportReceiveStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportReceiveStream ### Abort a send stream With abort() the browser may discard data that has not yet been sent. Without a WebTransportError reason, the spec sends error code 0. See the Errors section for aborting with a code. ```js const stream = await transport.createUnidirectionalStream(); const writer = stream.getWriter(); writer.write(new Uint8Array([65, 66, 67])); await writer.abort(); // pending data may be discarded ``` Sources: WebTransport.createUnidirectionalStream() (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/createUnidirectionalStream; WritableStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WritableStream; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## Datagrams ### Send datagrams with createWritable() MDN calls the datagrams.writable fallback "deprecated and non-standard" and prefers createWritable(); the W3C spec text I read lists only createWritable(). MDN currently marks this 'Baseline 2026, Newly available' (since March 2026) for the datagrams property. ```js const writable = typeof transport.datagrams.createWritable === "function" ? transport.datagrams.createWritable() : transport.datagrams.writable; // deprecated and non-standard const writer = writable.getWriter(); await writer.ready; writer.write(new Uint8Array([65, 66, 67])).catch(() => {}); ``` Sources: WebTransport.datagrams (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/datagrams; WebTransportDatagramDuplexStream.createWritable() (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportDatagramDuplexStream/createWritable; WebTransportDatagramDuplexStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportDatagramDuplexStream; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Read incoming datagrams Datagrams are unreliable: not guaranteed to arrive, and not in order. Only works on sessions that support unreliable transport. ```js const reader = transport.datagrams.readable.getReader(); for (;;) { const { value, done } = await reader.read(); if (done) break; console.log(value); // Uint8Array } ``` Sources: WebTransport.datagrams (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/datagrams; WebTransportDatagramDuplexStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportDatagramDuplexStream ### Respect maxDatagramSize maxDatagramSize is the largest outgoing datagram, in bytes, that may be written. It is read-only. ```js const writer = transport.datagrams.createWritable().getWriter(); const payload = new Uint8Array(200); if (payload.byteLength <= transport.datagrams.maxDatagramSize) { await writer.ready; writer.write(payload).catch(() => {}); } ``` Sources: WebTransportDatagramDuplexStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportDatagramDuplexStream; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Expire stale datagrams with incomingMaxAge and outgoingMaxAge Both are read/write and measured in milliseconds. Per the spec, 0 is stored as null, and a negative or NaN value throws RangeError. ```js transport.datagrams.incomingMaxAge = 2000; // milliseconds transport.datagrams.outgoingMaxAge = 2000; console.log(transport.datagrams.outgoingMaxAge); // null when no maximum age is set ``` Sources: WebTransportDatagramDuplexStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportDatagramDuplexStream; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Datagram queue-size attributes (names differ) (sources differ) MDN documents incomingHighWaterMark and outgoingHighWaterMark; the W3C spec text I read documents incomingMaxBufferedDatagrams and outgoingMaxBufferedDatagrams (minimum 1) instead. Probe for the name before using either. ```js const d = transport.datagrams; console.log("incomingHighWaterMark" in d); // named by MDN console.log("incomingMaxBufferedDatagrams" in d); // named by the W3C spec ``` Sources: WebTransportDatagramDuplexStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportDatagramDuplexStream; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ## Errors and aborting ### Inspect a WebTransportError source is "stream" or "session"; streamErrorCode is null if unavailable. MDN says the code is in the range 0-255, but the W3C spec defines an unsigned long, so treat the upper bound as unsettled. MDN currently marks this 'Baseline 2026, Newly available' (since March 2026). ```js try { await transport.ready; } catch (error) { if (error instanceof WebTransportError) { console.log(error.source, error.streamErrorCode); // "stream" | "session", number | null } else { throw error; // e.g. a SyntaxError for a bad URL } } ``` Sources: WebTransportError (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportError; WebTransportError() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportError/WebTransportError; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Abort a send stream or cancel a receive stream with a code (sources differ) Per the spec, abort and cancel use the reason's streamErrorCode when the reason is a WebTransportError, else 0, and clamp to 0-4294967295. The constructor signature disagrees: the spec shows (message, { source, streamErrorCode }) while MDN shows a single init object with message and streamErrorCode. ```js const send = await transport.createUnidirectionalStream(); await send.getWriter().abort(new WebTransportError("done", { streamErrorCode: 7 })); // for a server-opened receive stream: await receiveStream.getReader().cancel(new WebTransportError("unwanted", { streamErrorCode: 7 })); ``` Sources: WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/; WebTransportError() constructor (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportError/WebTransportError; WebTransportError (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportError; WebTransportSendStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportSendStream; WebTransportReceiveStream (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransportReceiveStream ## Feature detection ### Check that WebTransport exists In a worker, use typeof WebTransport !== "undefined" instead, since window is not defined there. The interfaces are exposed in Window and Worker contexts. ```js if ("WebTransport" in window) { // safe to construct a WebTransport } else { // fall back to WebSocket or another transport } ``` Sources: WebTransport.supportsReliableOnly (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/supportsReliableOnly_static; WebTransport (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Check for a secure context The WebTransport interfaces are marked SecureContext, so they exist only on https pages (or localhost). In workers, check self.isSecureContext. ```js if (!window.isSecureContext) { console.warn("WebTransport needs a secure context (https or localhost)"); } ``` Sources: Secure contexts (MDN): https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Secure_Contexts; WebTransport (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ ### Probe members that may be missing Treat newer members as optional. MDN currently marks congestionControl, reliability, createUnidirectionalStream(), WebTransportSendStream and WebTransportReceiveStream as 'Limited availability' (not Baseline), while the main WebTransport page shows 'Baseline 2026, Newly available' with partial-support asterisk. ```js const hasCreateWritable = typeof transport.datagrams.createWritable === "function"; const hasCongestionControl = "congestionControl" in WebTransport.prototype; const hasSendGroups = "createSendGroup" in WebTransport.prototype; const canFallBackToReliableOnly = WebTransport.supportsReliableOnly; // static boolean ``` Sources: WebTransport (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport; WebTransport.supportsReliableOnly (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/supportsReliableOnly_static; WebTransport.datagrams (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/datagrams; WebTransport.congestionControl (MDN): https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/congestionControl; WebTransport (W3C Working Draft): https://www.w3.org/TR/webtransport/ --- # Learn WebTransport Source: https://webtransport.day/learn/webtransport/ An ordered path from the basics to running and debugging your own server. 1. What is WebTransport? (https://webtransport.day/guides/what-is-webtransport/): Streams, datagrams, HTTP/3, QUIC and standards status. 2. WebTransport vs WebSocket (https://webtransport.day/guides/webtransport-vs-websocket/): When each is the better fit, and what WebRTC data channels are for. 3. Try it in the tester (https://webtransport.day/tools/webtransport-tester/): Connect from your browser to a server you choose. 4. Run a local test server (https://webtransport.day/guides/test-webtransport-locally/): Example servers and a self-signed certificate. 5. Debug handshake errors (https://webtransport.day/guides/debug-webtransport-handshake-errors/): A checklist for failed connections. 6. Pick a library (https://webtransport.day/guides/webtransport-client-libraries/): Client and server libraries and their stated caveats. 7. Serverless and edge limits (https://webtransport.day/serverless/): What providers document about hosting WebTransport. --- # WebTransport specification status Source: https://webtransport.day/spec-status/ Data fetched: 2026-10-28 - WebTransport (W3C API specification): Candidate Recommendation Snapshot, CR 2026-07-30, 2026-07-30 (https://www.w3.org/TR/webtransport/) - WebTransport over HTTP/3: Active Internet-Draft; WG state: In WG Last Call; IESG state: I-D Exists; intended status: Proposed Standard, rev 16, 2026-07-06 (https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/) - The WebTransport Protocol Framework: Active Internet-Draft; WG state: In WG Last Call; IESG state: I-D Exists; intended status: Proposed Standard, rev 13, 2026-07-06 (https://datatracker.ietf.org/doc/draft-ietf-webtrans-overview/) - WebTransport over HTTP/2: Active Internet-Draft; WG state: In WG Last Call; IESG state: I-D Exists; intended status: Proposed Standard, rev 15, 2026-07-06 (https://datatracker.ietf.org/doc/draft-ietf-webtrans-http2/) - QUIC: A UDP-Based Multiplexed and Secure Transport: Proposed Standard, RFC 9000, 2021-05 (https://www.rfc-editor.org/rfc/rfc9000) - HTTP/3: Proposed Standard, RFC 9114, 2022-06 (https://www.rfc-editor.org/rfc/rfc9114) - An Unreliable Datagram Extension to QUIC: Proposed Standard, RFC 9221, 2022-04 (https://www.rfc-editor.org/rfc/rfc9221) - HTTP Datagrams and the Capsule Protocol: Proposed Standard, RFC 9297, 2022-08 (https://www.rfc-editor.org/rfc/rfc9297) --- # WebTransport implementations Source: https://webtransport.day/implementations/ Data fetched: 2026-10-28 - undefined (undefined, undefined): license Apache-2.0; latest release [object Object]; last commit 2026-09-22T06:05:11Z - undefined (undefined, undefined): license Apache-2.0; latest release [object Object]; last commit 2026-10-28T17:11:25Z - undefined (undefined, undefined): license MIT; latest release [object Object]; last commit 2026-02-09T00:58:24Z - undefined (undefined, undefined): license MIT; latest release [object Object]; last commit 2026-10-26T07:18:24Z - undefined (undefined, undefined): license BSD-3-Clause; latest release [object Object]; last commit 2026-10-16T19:13:06Z - undefined (undefined, undefined): license unknown; latest release [object Object]; last commit 2026-10-24T05:33:43Z - undefined (undefined, undefined): license BSD-3-Clause; latest release unknown; last commit 2026-10-28T18:46:15Z - undefined (undefined, undefined): license MIT; latest release unknown; last commit unknown