WebSocket Tester

WebSockets keep a connection open between a browser and a server so both can send messages at any time, which is how chat, live dashboards, multiplayer games and price feeds work. When something goes wrong, the first question is whether the server accepts connections and what it actually sends. This tester connects to a WebSocket URL from your browser, lets you send messages and logs every frame.

Opening a connection

A WebSocket starts as an HTTP request with an Upgrade: websocket header; if the server agrees, it answers with status 101 and the connection switches protocols. Browsers perform this handshake themselves and expose only the result, so the tester shows “Connected” with the negotiated subprotocol and extensions such as permessage-deflate, or an error if the handshake fails.

Secure and local URLs

This page is served over HTTPS, and browsers block unencrypted connections from secure pages as mixed content. The tester therefore accepts wss:// URLs, plus ws:// to localhost, 127.0.0.1 or ::1, which browsers treat as trustworthy for local development. Any other ws:// address is refused with an explanation instead of failing silently.

Subprotocols

Many servers speak an application protocol on top of WebSocket and negotiate it during the handshake: GraphQL subscriptions use graphql-transport-ws, MQTT over WebSocket uses mqtt, and STOMP uses names such as v12.stomp. Enter one or more names, separated by commas, before connecting; the server picks one and the tester displays which.

Frames and messages

Each frame in the log shows whether it was sent or received, the time since the connection opened, its size in bytes and its content. Text frames containing JSON can be pretty-printed. Binary frames, which the browser delivers as array buffers, are shown as hexadecimal bytes. Press Ctrl+Enter to send the message box’s content as a text frame.

Closing and close codes

When the connection ends, the close code and reason are logged. 1000 is a normal close and 1001 means the server is going away. 1006 is not sent by servers at all: the browser reports it when the connection dropped without a proper close frame, for example after a network failure, a proxy timeout or a handshake the server refused. Browsers deliberately hide the details, so check server or proxy logs for the cause.

A worked example

Entering ws://example.com/x and pressing Connect is refused with the message that browsers block unencrypted ws:// from an https page except to localhost. Entering http://example.com is refused because the URL must start with wss://. With a valid address, such as one of the public echo servers listed under the URL field, the Sample message, a JSON subscription request, is sent as a text frame; an echo server returns each message unchanged, so it appears in the log once as sent and once as received.

Authentication and privacy

The browser WebSocket API cannot set custom headers, so there is no way to send an Authorization header. Servers designed for browsers accept a token in the URL query string, a cookie for their own domain, a value in Sec-WebSocket-Protocol or credentials in the first message. Nothing is sent until you press Connect, and then only to the server you entered. The echo servers offered as quick picks are run by third parties, so do not send secrets to them.

Related tools

• cURL to Code turns the HTTP handshake request into code.
• JWT Decoder inspects tokens passed to the server.
• HTTP Status Codes explains 101 and the handshake errors.
• JSON Formatter tidies captured messages.