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