# WebTransport tester: connect and echo from your browser > 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. URL: https://webtransport.day/tools/webtransport-tester/ Updated: 2026-10-28 Facts checked: 2026-10-28 **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. This tool runs in the browser and needs JavaScript; the sections below describe what it does. ## 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. ## FAQ ### 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/)