Can I test ws://localhost or a LAN server from this HTTPS page?
It depends on the browser (as of October 2026). Chrome 147 and later treats WebSocket connections to your computer or local network as local network access: the first time, it asks whether to allow this site, and after you choose Allow, ws://localhost, ws://127.0.0.1 and ws:// to a LAN IP address such as 192.168.1.10 connect. In Chrome the LAN server must be written as an IP address; a plain host name (other than .local) is blocked even if it resolves to your network. Firefox connects to localhost directly but blocks ws:// to LAN addresses. Safari blocks ws:// to localhost and the LAN from HTTPS pages. wss:// is not affected by the mixed-content rule: public servers work from this page in every browser as long as the certificate is trusted; for localhost or LAN addresses, Chrome asks for local network permission first here too.
Why can't I connect to ws://example.com from this page?
This page is served over HTTPS, and browsers block an unencrypted ws:// connection to a public host from an HTTPS page (mixed content). Chrome and Firefox refuse immediately with a SecurityError, which the tool reports. Use the server's wss:// address. Public sites served over plain http do not have this rule, but in recent Chrome they cannot reach localhost or your LAN at all.
The connection failed with code 1006 — what went wrong?
1006 only means the connection ended without a closing handshake. When a handshake fails, the WebSocket standard requires the browser to hide the cause from the page — a 401, a 404, a refused port, a certificate error and a rejected Origin all look identical (Firefox reports certificate errors as 1015) — so no web tester that connects straight from the browser can show it. Press F12 and open the Console: Chrome and Edge print the HTTP status the server returned. The tool also separates failures before the connection opened from drops after it was open and lists the usual causes for each.
Can I add an Authorization or other custom header?
No. The browser WebSocket API does not let web pages set request headers; the browser sends a fixed set (including Origin and cookies for the server's own site). Common workarounds, depending on what your server supports: a token in the URL, such as wss://host/ws?token=…; a token passed as a subprotocol (only token characters are allowed, so JWT works but standard Base64 with = or / does not, and the server must echo the subprotocol back); or a cookie, which browsers send reliably only to the page's own site, so from this page it usually does not reach your server. Tools such as Postman can set headers because they are not browsers.
Why does it work in Postman but not here?
Postman and command-line clients can set any header and usually send no Origin. A browser cannot add an Authorization header and always sends Origin: https://go-tools.org. If the server needs a header token or checks Origin, it rejects the browser's handshake; allow the Origin or pass the token another way.
Does the heartbeat send WebSocket ping frames?
No. Web pages can neither send nor see protocol-level ping/pong frames; when the server sends a ping, the browser answers with a pong by itself. Timed send here sends an ordinary text message, such as {"type":"ping"}, at the interval you set. It is off by default because a server that does not expect that message may close the connection. To keep an idle connection alive through a proxy, have the server send pings.
Why can't I connect to my Socket.IO server?
Socket.IO is a protocol on top of WebSocket, not plain WebSocket. A Socket.IO v3/v4 server expects the path /socket.io/?EIO=4&transport=websocket, sends an open packet starting with 0, expects 40 to join the default namespace, and closes the connection if each ping 2 is not answered with pong 3. Choose the Socket.IO preset and the tool does all of this; then send events as 42["event","data"]. Servers configured for HTTP long-polling only will not accept a WebSocket at all.
My connection drops after about a minute — why?
Usually an idle timeout in a reverse proxy. Nginx closes a proxied connection when no data passes for 60 seconds by default (proxy_read_timeout), and the page sees code 1006. Raise the timeout or have the server send ping frames. Behind Nginx, also make sure the proxy forwards the upgrade with proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade"; (before Nginx 1.29.7, also proxy_http_version 1.1;).
How do I connect to a wss:// server with a self-signed certificate?
Open https://the-same-host:port/ in a new tab, accept the certificate warning, then come back and connect. The browser remembers the exception for that host and port. Only do this for your own test servers, because it lowers the browser's protection.
How do I send and read binary messages?
Choose HEX or Base64 as the send format. HEX accepts 48 69 00 FF, 0x48,0x69 or 486900FF; the preview shows the bytes, and invalid characters or an odd number of digits are reported with their position instead of being sent. Received binary messages are shown as HEX, 16 bytes per line, and the log toolbar switches them to Base64. To read received HEX as text, paste it into Hex to String. Do my messages go through go-tools servers?
No. Your browser connects directly to the address you enter, and messages do not pass through our servers. The tool also opens no WebSocket connection until you press Connect, and it keeps the address and messages only in memory — not in the page URL or browser storage. Like the rest of the site, this page loads analytics and advertising scripts.
Is there a server I can test against?
Use the local echo: it runs inside this page, echoes everything you send and makes no network connection. Public echo services such as wss://echo.websocket.org/ also exist, but they are third-party: availability is not guaranteed, and your messages go to that third party.