Test WebSocket servers straight from your browser
This WebSocket tester is a small client for ws:// and wss:// endpoints. Enter a URL and optional subprotocols, connect, and send text, JSON (validated and minified before sending) or raw binary typed as hex bytes. Every frame in either direction lands in a timestamped log showing its size; JSON is pretty-printed and binary messages are shown as a hex dump with a text preview.
For long-running sessions it can send an application-level ping message on an interval and reconnect automatically with exponential back-off when the connection drops. Close codes are explained in plain language (1006 abnormal closure, 1008 policy violation, 1011 server error…), frequently used messages can be saved, and the whole log exports as JSON or text for a bug report.
The socket is opened by your browser directly to the server — there is no relay — and saved messages are kept only in this browser’s local storage.
How to use the WebSocket Tester
- Enter the Server URL, beginning with
wss://(orws://localhostfor a local server), and any Subprotocols your server expects, such asgraphql-transport-ws. - Press Connect. The status badge turns to Open and the log shows which subprotocol the server chose.
- Pick Text, JSON or Binary (hex), type the message and press Send (or Ctrl+Enter).
- Turn on Auto-ping to keep idle connections alive and Auto-reconnect to recover from drops.
- Save messages you reuse, then Export JSON or Export text to share the session, and Disconnect when done.
WebSocket Tester features
Three message types
Plain text, JSON with syntax checking and minification, and binary frames built from hex such as 48 65 6c 6c 6f or 0x01,0x02, sent as an ArrayBuffer.
Readable log
Millisecond timestamps, direction arrows, byte sizes, pretty JSON and hex dumps with a UTF-8 preview; the newest 2,000 entries are kept.
Keep-alive and reconnect
A configurable ping message every N seconds, and reconnection after unexpected closes with back-off from 0.5 s doubling to a 30 s ceiling — never after you disconnect yourself.
Close-code explanations
Codes from RFC 6455 and the IANA registry are translated, with likely causes for 1006, the most common and least informative code.
Saved messages and export
Up to 30 named messages per browser, and full log export as structured JSON or plain text.
What a browser WebSocket client cannot do
Browsers deliberately restrict the WebSocket API, and this tester inherits those limits:
- No custom headers. You cannot add
Authorizationor other headers to the handshake. Pass a token in the URL query, in the first message after connecting, via a cookie set by the same site, or through theSec-WebSocket-Protocolsubprotocol list (a common workaround). - No protocol ping/pong frames. Browsers answer server pings automatically but cannot send their own control frames, so auto-ping sends an ordinary message your server must recognise.
- Mixed content. An
https://page may only openwss://connections, except to localhost. - Origin checks. CORS does not apply to WebSockets, but servers often reject handshakes whose
Originheader is not their own site; that shows up as close code 1006. - Opaque errors. For security, the browser does not reveal why a handshake failed. The DevTools Network panel (WS filter) shows the HTTP status of the upgrade request.
Common close codes
| Code | Meaning | Typical cause |
|---|---|---|
| 1000 | Normal closure | Either side finished cleanly |
| 1001 | Going away | Server shutting down or the page navigating away |
| 1006 | Abnormal closure | Handshake refused (wrong path, auth, Origin), TLS problem, network drop — no close frame was received |
| 1008 | Policy violation | Authentication or authorisation failed |
| 1009 | Message too big | Frame exceeds the server’s size limit |
| 1011 | Internal error | Unhandled exception on the server |
| 1012 / 1013 | Service restart / try again later | Deploys and overload — reconnect with back-off |
Related tools
Many WebSocket services start with an HTTP call to fetch a token; build and send that with the HTTP Request Builder. Inspect large JSON payloads from the log in the JSON Formatter, decode Base64 fields with the Base64 encoder/decoder, and analyse a recorded browser session, including WebSocket entries, with the HAR File Viewer.
WebSocket Tester FAQ
How do I test a WebSocket connection online?
Enter the wss:// URL in the WebSocket tester, press Connect and send a message. If the status turns Open and replies appear in the log, the server is reachable and speaking WebSocket. An echo server sends every message straight back, which is handy for a first test.
Why does my connection close immediately with code 1006?
1006 means the connection ended without a proper close frame. Usually the handshake was rejected: a wrong path, missing authentication, an Origin the server does not allow, an invalid TLS certificate, or a proxy that does not support upgrades. Check the upgrade request in DevTools → Network → WS.
Can I send an Authorization header?
Not from a browser — the WebSocket API has no way to set handshake headers. Use a token in the query string, a first “auth” message, a same-site cookie, or a subprotocol value if your server supports that pattern.
Is my data sent through your servers?
No. The browser connects directly to the URL you enter. Messages, the log and saved messages never pass through any other server; saved messages stay in local storage until you delete them.
What does auto-ping send?
The text in the ping box (by default {"type":"ping"}) as a normal message every few seconds. Browsers cannot send protocol-level ping frames, so configure the text to whatever your server treats as a heartbeat.
Can I connect to ws://localhost?
Yes. Browsers allow unencrypted WebSockets to localhost even from an https page, so you can test a development server on your own machine.