WebSocket Tester / Client

Connect to any ws:// or wss:// endpoint, declare optional sub-protocols, send text or JSON messages and watch a full lifecycle log: ready-state transitions, close codes and reasons, and every message with its direction, time and payload. Everything runs locally in your browser using the native WebSocket API — nothing is routed through a server. For plain HTTP APIs use the REST API Client / Tester; see the whole API Tools family.
CLOSED Send welcome JSON on connect
Message log 0 events
Nothing yet. Connect to a server to begin.
Browser WebSocket limitations to know: request headers cannot be customized (only cookies and the Sec-WebSocket-Protocol sub-protocol above are sent); the handshake is not governed by CORS, but the page Content-Security-Policy connect-src can block it; a secure (https) page can only open wss://; JavaScript cannot send protocol-level ping frames (the browser answers server pings automatically — use app-level messages such as {"type":"ping"} to simulate heartbeats); self-signed certificates are not trusted. Recommended for local testing: run your own server, or use a public echo like wss://ws.postman-echo.com/raw or wss://echo.websocket.org.
WebSocket explained
A WebSocket gives you a two-way, persistent message channel between the browser and a server. Unlike HTTP, messages can travel both directions over a single connection.
ws:// vs wss:// — ws:// is unencrypted (like http://); wss:// is encrypted (like https://). If this page is served over HTTPS, the browser only allows wss:// connections. From a local file (file://) both schemes are permitted, but many public echo servers (including echo.websocket.org) only accept wss://.
Sub-protocols — the optional comma-separated list maps to the Sec-WebSocket-Protocol handshake header. The server must support one of them, otherwise the browser refuses the connection.
Why does Connect finish but no “Send message” box appear? The send form only appears when the state becomes OPEN. If the server drops the handshake, you will see an error event followed by CLOSED code 1006 (abnormal closure — no close frame). Typical causes: using ws:// against a server that only accepts wss://, a wrong host/port, a sub-protocol mismatch, or the server being offline.
Close codes you may see — 1000 normal; 1001 browser tab closing; 1006 abnormal / handshake failed; 1009 message too large; 1011 server error. The log shows the code and a short reason automatically.
Troubleshooting a failed connect: first switch the scheme to wss://, make sure the host is reachable, clear any sub-protocols you do not need, and check the browser console for TLS or mixed-content errors.