WebSocket Tester
Connect to a WebSocket server, exchange text or binary messages and inspect connection events.
Connect and Send transmit data directly to the specified server.
Connect, exchange messages, then close
Enter a ws:// or wss:// URL and optional comma-separated subprotocol tokens. Example fills an illustrative address without connecting. Connect starts a session; Send is available only after the server opens it. Changing the URL or subprotocols closes the old session and clears its log. Changing message or close fields keeps the current connection.
Text is encoded as UTF-8. Binary input is pairs of hexadecimal digits with optional whitespace; incoming binary frames are shown as hex. Empty messages are supported. The server’s selected subprotocol, sent/received counts and close event appear in the report.
A browser WebSocket client
Secure pages normally require wss://. Browser mixed-content, TLS and server Origin checks still apply; errors do not reveal a reliable handshake HTTP status. Browser WebSocket cannot set arbitrary handshake headers or send control Ping/Pong frames. Socket.IO and MQTT are separate protocols and cannot be tested by treating their messages as raw WebSocket application data.
The close code must be 1000 or 3000-4999; the reason is limited to 123 UTF-8 bytes. A closing request is not reported as closed until the actual close event arrives. Connection setup times out after 10 seconds; a new session ignores late events from an older one.
Logs and resource limits
A session retains at most 1,000 event records and 2 MiB of serialized event data. Exceeding the limit requests closure using application code 4009 and reports dropped records. Each sent or received message is limited to 1 MiB; sending is rejected while the outgoing queue would exceed 1 MiB. A browser can receive data before these checks run because WebSocket has no streaming backpressure API.
The full JSON export contains the retained log, timestamps, close information and counts. Preview stops at 200,000 characters. Clear disconnects and resets the session; leaving the page requests closure. No session is automatically reconnected or saved in local storage.
Questions & answers
Does Example contact a public echo service?
No. Supply your own endpoint and select Connect explicitly.
Can I use custom authentication headers?
Not through the browser WebSocket constructor. Use the server’s supported cookie, URL or subprotocol mechanism and review what data it transmits.
Other Languages
References
How we make sure
We check this tool with the automated test suites linked below. Example checks are shown in their original language.
- Verification method
- Check URLs, subprotocols, close reasons/binary messages and lifecycle/stale-event handling with controlled events.
- Comparison reference
- Fixed message bytes and controlled WebSocket lifecycle assertions.
- Verification scope
- These samples and boundaries do not prove correctness for every input.
Test source and cases (select a file to read it)
-
live-network-tools.test.js
- WebSocket validates URLs, protocol tokens, payload encoding and close reason UTF-8 length
- WebSocket lifecycle logs text and binary messages and waits for a real close event
These checks cover the listed examples and boundaries, not every possible input. Round trips and checks using the same library are not independent verification.