WebSocket Tester

Connect to a WebSocket endpoint, send and receive messages, and see a live message log with timestamps.

How to Use WebSocket Tester

1

Enter WebSocket URL

Type the ws:// or wss:// endpoint URL to connect to.
2

Connect and send

Click connect, then type and send messages to the server.
3

View the log

See all sent and received messages in the activity log.

Tested tool guide Tested browser tools Checked August 16, 2026

What WebSocket Tester does and how it behaves

This tool opens a live connection to a ws:// or wss:// URL you supply, then gives you a box to type outgoing messages and a scrolling log that appends every sent and received frame with a timestamp and direction marker. It relies on the browser's built-in WebSocket object, so the handshake, close codes, and error events are exactly what a real client on that page would experience. The detail people miss most: the WebSocket API gives no way to set custom handshake headers, so an Authorization header cannot be attached here - any token has to ride in the URL's query string, a subprotocol, or a post-connect message instead.

How the result is produced

Connection lifecycle

Entering a URL and connecting runs the standard WebSocket handshake and tracks readyState through CONNECTING, OPEN, CLOSING, and CLOSED. If the server rejects the upgrade or the connection drops, the tool surfaces the close code and reason string exactly as reported by the onclose event, rather than a generic failure message.

Message log

Every frame you send and every message the server pushes back is appended to a single chronological log entry with a wall-clock timestamp and a sent/received tag. Text frames are shown as-is; the log does not attempt to reformat, pretty-print, or validate JSON payloads before display, so malformed JSON still appears verbatim.

Good uses

checking that a newly deployed WebSocket server accepts a connection and echoes the expected payload before wiring it into an application
watching the raw message stream from a chat, ticker, or game-state endpoint to see exactly what a client receives when a bug report mentions dropped or garbled updates
confirming a wss:// endpoint's handshake and close code when a native or mobile client is reporting connection failures you can't reproduce from its logs alone

Limits and checks

you cannot attach a custom Authorization or cookie header to the handshake - the browser WebSocket API doesn't expose that, so auth has to go through the URL, a subprotocol, or a first message
if this tool's page is loaded over https, browsers block plain ws:// (mixed content); you'll need a wss:// endpoint or an http-served copy of the tool to test unencrypted servers
the connection lives only as long as the tab stays open and there is no automatic reconnect, so a server that drops idle connections will simply show as closed rather than being retried

Common questions

Can I send an Authorization header when connecting?

No. Browsers do not allow custom headers on the WebSocket handshake, and this tool can't work around that restriction since it uses the same API a page's own JavaScript would use. Pass the token as a URL query parameter, negotiate it as a subprotocol, or send it as the first message if your server supports that.

Will this work against a plain ws:// (non-TLS) server?

Yes, as long as the tester page itself isn't loaded over https - mixed-content rules block an https page from opening a ws:// connection. If your endpoint is unencrypted, use wss:// on the server side or access the tool over http.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.