Public WebTransport echo servers: history, status and alternatives

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), so a reply can be lost.

Text version

1. The browser sends "hello" to the server on a stream (blue) or as a datagram (amber).
2. The echo server sends the same bytes back (teal-green).
3. The browser shows the echo. If it arrives, DNS, UDP, QUIC, HTTP/3, the certificate and the origin check all worked.

How does an echo server work?

A browser opens a connection with new WebTransport(url), as defined by the W3C WebTransport specification and documented on MDN. 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, 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 guide explains the handshake; the 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, 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, the earliest we found.
• 2022 to 2026. The homepage was a browser test page. An archived copy from 28 March 2023 and one from 10 May 2025 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. 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 shows a different test page, pointed at https://usa.echo.webtransport.day/serverless. See what that URL holds now.
• 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. 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.

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. 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. 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. |

Try echo.semantic-ui.com in the tester. 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 | Python server, JS client | The same sample the hosted servers above run. | | 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 | Rust | The full example is a server and browser page, but it replies ACK instead of echoing the bytes. | | webtransport-go | Go | Runnable client and server in example/. Its README does not say whether it echoes. | | Chrome samples | Python (aioquic) | The server is not an echo: it answers on /counter with a count of the bytes received. |

See test WebTransport locally for steps and the 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 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 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.