WebSocket Tester
not connected
Enter the WebSocket URL, starting with wss:// — for example wss://api.example.com/socket.
Optionally list subprotocols (comma-separated) to offer during the handshake, such as graphql-ws.
Click Connect: the status chip shows the handshake time and which subprotocol the server accepted.
Type a message and press Enter to send a frame; incoming frames appear in the live feed with timestamps.
On disconnect, the close code is decoded for you — including the infamous 1006 abnormal closure.
When a WebSocket endpoint misbehaves, the usual debugging loop involves installing wscat or postman just to answer one question: does it accept connections at all? This tester answers it in seconds. Enter a wss:// URL, click Connect, and you see the handshake result, the time it took, and the subprotocol the server picked — then a live console for sending frames and watching what comes back, timestamped to the millisecond.
Because the browser WebSocket API needs no CORS preflight, any reachable endpoint can be tested: API gateways, GraphQL subscription servers, Socket.IO backends (raw frame level), trading feeds or your own dev deployment. The connection is made directly from your browser to the server — unlike online testers that funnel traffic through their own relay, no third party sits in the middle.
100% private“The connection runs directly between your browser and the server you enter — nothing is proxied, logged or observed by this site. The URL and every frame you send exist only in your tab.”
This site is served over https, and browsers block plain-text WebSocket connections from secure pages as mixed content — with one exception: loopback. ws://localhost and ws://127.0.0.1 are treated as trustworthy, so a server running on your own machine is fully testable here. Anything remote needs its TLS listener (wss://).
Browsers deliberately hide the low-level failure reason from JavaScript to prevent port-scanning. Code 1006 can mean DNS failure, an invalid certificate, a closed port, or a proxy dropping the upgrade — check the browser devtools network tab and the server logs to narrow it down.
At the raw frame level, yes — but those libraries speak their own protocol on top of WebSocket (handshake packets, heartbeats), so a bare connection may be closed by the server unless you send the frames it expects. For full protocol testing, use their own client libraries.
Browsers cannot attach an Authorization header to a WebSocket handshake, and reject URLs with embedded user:pass credentials — that is a platform rule, not a limitation of this tool. Servers therefore authenticate WebSockets in one of three ways, all testable here: a token in the URL query string (paste the full URL), a token passed as a subprotocol (use the subprotocols field), or an auth message sent right after connecting (type it in the console). Cookies also ride along automatically for same-site endpoints.