WebSocket Tester
Connect to any ws:// or wss:// endpoint, send messages, and inspect live events with timestamps. 100% client-side.
WebSocket Event Reference
| Event | Description |
|---|---|
| OPEN | Connection established. Ready to send and receive messages. |
| Message received from the server. JSON is auto-detected and pretty-printed. | |
| SEND | Message sent to the server from this client. |
| ERROR | A connection error occurred. Often followed by a CLOSE event. |
| CLOSE | Connection closed. Shows close code and reason if provided by the server. |
Close Codes
| Code | Meaning |
|---|---|
| 1000 | Normal Closure — clean, intentional close |
| 1001 | Going Away — server shutting down or page navigation |
| 1002 | Protocol Error — invalid framing |
| 1003 | Unsupported Data — binary data when text expected |
| 1006 | Abnormal Closure — connection lost without close handshake |
| 1007 | Invalid Frame Payload Data — not valid UTF-8 |
| 1008 | Policy Violation — server rejected the message |
| 1009 | Message Too Big — payload exceeds server limit |
| 1011 | Internal Error — server encountered unexpected condition |
| 1015 | TLS Handshake — TLS failure (not sent over the wire) |
Public Test Endpoints
wss://echo.websocket.org— echoes back everything you sendwss://ws.postman-echo.com/raw— Postman echo serverwss://socketsbay.com/wss/v2/1/demo/— public demo channel
How to Use the WebSocket Tester
- Enter a URL — type or paste a
ws://orwss://URL in the field at the top. - Click Connect — the indicator turns green when the connection is established.
- Watch the log — open, receive, send, error, and close events appear in the event log with timestamps.
- Send messages — type any text or JSON in the send box and click Send. JSON is auto-detected and pretty-printed in the log.
- Disconnect when done — the connection is closed cleanly and the log shows the close code.
What This Tool Does
This WebSocket tester establishes a direct WebSocket connection from your browser to any URL you enter. It logs all lifecycle events — onopen, onmessage, onerror, and onclose — with precise timestamps. Messages are inspected: if the server sends valid JSON, the tool automatically pretty-prints it for easy reading. Your connection history is saved to localStorage so frequently used endpoints are one click away.
WebSocket vs HTTP Polling
Traditional HTTP requires the client to send a request before the server can respond — every real-time update requires a new request (polling). WebSocket eliminates this by opening a persistent, bidirectional channel where both sides can push data at any time. This makes WebSocket dramatically more efficient for applications that need frequent updates: a stock price feed that updates 10 times per second would require 10 HTTP requests per second per client under polling, versus a single always-open WebSocket connection. The protocol upgrade from HTTP to WebSocket happens via a standard HTTP request with the Upgrade: websocket header, after which the connection is handed off to the WebSocket protocol.
Testing gRPC-Web and GraphQL Subscriptions
WebSocket is also the transport layer for GraphQL subscriptions and some gRPC-Web implementations. When testing a GraphQL subscription server, you typically send a connection init message like {"type":"connection_init"} and then subscribe with a start message. The server responds with connection_ack and then streams data messages. This WebSocket tester lets you manually replicate that handshake to verify your subscription server responds correctly before wiring it up to a client library.
Debugging Connection Issues
When a WebSocket connection fails, the event log shows the exact close code, which is the most reliable diagnostic signal. A code of 1006 (Abnormal Closure) usually means the TCP connection dropped without a clean WebSocket close — often caused by a firewall, proxy, or load balancer that does not support WebSocket upgrades. Code 1015 indicates a TLS certificate problem on the server. If the connection never reaches the OPEN state, the server may be rejecting the upgrade request, which can be diagnosed via the browser's Network tab (look for a 101 Switching Protocols response). The Reference tab in this tool documents all standard close codes.
Security Notes
Always use wss:// in production — it encrypts all traffic via TLS, preventing man-in-the-middle attacks. Browsers enforce a mixed content policy: a page loaded over HTTPS cannot open an unencrypted ws:// connection. If you need to test a local development server that uses plain ws://, either access this page via HTTP or configure your local server with a self-signed TLS certificate and use wss://. Never send sensitive credentials, tokens, or PII via an unencrypted WebSocket connection. Message history saved by this tool stays entirely in your browser's localStorage — nothing is sent to our servers.
Related Tools
For API testing beyond WebSocket, try the JSON Formatter to inspect server payloads. If your WebSocket server uses Protocol Buffers, use the Protobuf Schema Preview to understand the message structure before testing. The JWT Decoder is useful for inspecting authentication tokens your WebSocket server might require in the initial handshake headers.