WebSocket Online Test Tool
Online WebSocket connection test, message sending and receiving debugging tool
What is WebSocket?
The WebSocket Test connects to a WebSocket URL and helps verify whether a real-time channel can open, send messages, and receive responses. WebSockets are used for chats, live dashboards, notifications, multiplayer features, market data, device communication, and other long-lived bidirectional connections. The tool helps during development, troubleshooting, proxy setup, TLS checks, and comparisons between ws:// and wss:// endpoints. It is not a load test or a complete protocol analyzer. Authentication, subprotocol negotiation, heartbeat behavior, reconnect strategy, message format, backpressure, and server limits still need to be tested in the real client and deployment environment. A successful connection only proves one path works under the current conditions.
How to Use
How to use
- Enter the WebSocket server address in the URL field (ws:// or wss://)
- Optional: enter subprotocols, separated by commas for multiple
- Click 'Connect' to establish WebSocket connection
- Enter the message content in the input field
- Select message type (Text or JSON), JSON type will auto-validate format
- Click 'Send' or press Ctrl + Enter to send message
- View sent and received messages in the message list, click to copy
Connection Tips
- Use wss:// when testing from an HTTPS page; browsers often block insecure ws:// connections from secure origins.
- Export or copy important message logs before disconnecting, refreshing, or switching endpoints during debugging.
Use Cases
Technical Principle
The core of the WebSocket protocol is the HTTP Upgrade. The client first sends a regular HTTP GET request, but with the Upgrade: websocket and Connection: Upgrade headers and a randomly generated Sec-WebSocket-Key. After validating these headers, the server responds with 101 Switching Protocols, including the Sec-WebSocket-Accept value, which is the SHA-1 of the Key concatenated with a fixed GUID, then Base64 encoded. After the 101 response, the TCP connection switches from HTTP to WebSocket, and subsequent data is transmitted as WebSocket frames. A WebSocket frame header is at least 2 bytes, containing the FIN flag, the opcode (0x1 text, 0x2 binary, 0x8 close, 0x9 ping, 0xA pong), and the payload length. ping/pong frames are used for heartbeat detection; the browser API does not send them automatically, so the application layer must implement them. wss:// is the equivalent of HTTPS+WebSocket, doing a TLS handshake first and then the WebSocket upgrade; ws:// is plaintext, and the browser will refuse ws:// endpoints on https pages to prevent downgrade attacks. A single frame is capped at about 1MB by default; longer messages are split across multiple frames.
- Handshake: the client sends an HTTP GET with the Upgrade: websocket header, and the server returns 101 Switching Protocols to signal a successful upgrade
- Sec-WebSocket-Key is a 16-byte Base64 string generated randomly by the browser; the server concatenates a fixed GUID, takes the SHA-1, and verifies via Sec-WebSocket-Accept
- Framing: every frame carries a header of at least 2 bytes, with FIN, opcode (text/binary/ping/pong/close), and the payload length
- ws:// is plaintext, wss:// is WebSocket over HTTPS; browsers refuse ws:// on https sites to prevent downgrade attacks
- ping/pong frames for heartbeats: RFC 6455 requires a pong in response to every ping; the browser does not send heartbeats automatically, the application must implement them
- Close sequence: either side sends a 0x8 close frame with a status code, the peer replies with a matching close frame, and only then is the TCP connection actually released
Examples
Connect to a Public Echo Service
wss://echo.websocket.org — 101 Switching Protocols handshake succeeds, sending "hello" immediately echoes back "hello"Debug Your Own WebSocket Service
wss://api.example.com/ws — subprotocol graphql-ws, connection succeeds, subscription messages received normallyReproduce a Dropped Connection
wss://api.example.com/ws — the server actively closes the connection 30 seconds after establishment, close code 1006 (abnormal closure)FAQ
What does the WebSocket tester do?
Lets you connect to any ws:// or wss:// endpoint, send and receive messages, and inspect the protocol exchange. Useful for testing WebSocket APIs, MQTT-over-WS brokers, real-time game servers, chat systems, and stock-quote feeds during development.
Are messages sent through your servers?
No. The browser opens the WebSocket connection directly to the target host. No intermediary, no logging on our side. The target host sees your IP just like any other client.
Why won't it connect to my localhost endpoint?
Mixed-content rules: if this page is served over HTTPS, browsers block ws:// (insecure) connections. Use wss:// for the target, or run this page over plain HTTP for local testing. Browser console shows the exact rejection reason.
Can I send binary data?
Yes. Most builds support text and binary frames. Binary input is typically Base64 or hex; the page decodes before sending. Display of binary responses uses hex or Base64 by default.
How do I add custom headers?
Browser WebSocket API doesn't allow custom headers - that's a Web Platform restriction. The only header you can set is Sec-WebSocket-Protocol (the subprotocol). For Bearer token auth, use a query parameter or first-message authentication; some servers accept a Cookie.
Will it test compression and extensions?
Browsers negotiate per-message-deflate automatically with servers that advertise it. The page typically shows the negotiated extension. Custom extensions are not tested - browsers don't expose that level of control.
Why does my connection keep dropping?
Common causes: the server's idle timeout (often 30-120 s), proxy/load-balancer timeout, network interruption, or your laptop sleeping. Modern WebSockets need ping/pong heartbeats; verify the server is sending pings, or have your client send periodic messages.