📋 Message Log
Connect to a WebSocket endpoint to see messages.
Send Message
0 chars
Tip: Ctrl+Enter to send
Connect to ws:// or wss:// endpoints, send messages, and inspect frames in real time.
Tip: Ctrl+Enter to send
WebSocket Tester connects to any WebSocket endpoint (ws:// or wss://) and lets you send and receive messages interactively. Enter a WebSocket URL, click Connect, and type messages to send — responses appear in the log with timestamps. It supports custom connection headers, JSON message formatting, message history, and real-time connection status monitoring.
WebSocket is a full-duplex communication protocol over a single TCP connection. Unlike HTTP (request-response, client initiates), WebSocket allows both client and server to send messages at any time after the initial handshake. The WebSocket handshake is an HTTP Upgrade request that switches the protocol from HTTP to WebSocket. WebSockets are used for: real-time chat, live notifications, collaborative editing (Google Docs-style), financial tickers, gaming, and any application needing bi-directional low-latency communication.
WebSocket URLs: ws:// (unencrypted, not recommended for production) and wss:// (WebSocket Secure, TLS-encrypted, same as HTTPS for WebSockets). Many WebSocket APIs require specific headers for authentication (Authorization, X-API-Key) or subprotocol negotiation. The server indicates which subprotocol it selected in the Sec-WebSocket-Protocol response header.
Test echo server
Result: Connect to wss://echo.websocket.events → send 'Hello' → receive 'Hello' echoed back
Send JSON message
Result: {"action":"subscribe","channel":"prices"} → toggle JSON formatting for readable output
Monitor connection events
Result: Log shows: Connected → Message received: {...} → Ping/Pong → Disconnected
What is the difference between WebSocket and HTTP long polling?
Long polling: client sends an HTTP request, server holds it open until data is available, then responds and the client immediately sends another request. Inefficient (constant reconnection overhead), unidirectional (server→client push), but works without WebSocket support. WebSocket: single TCP connection stays open indefinitely, both sides can send at any time, much lower latency and overhead. WebSocket requires explicit server support; long polling works on any HTTP server.
How do WebSockets handle authentication?
Unlike HTTP where you can set headers on any request, WebSocket upgrade requests from browsers cannot include custom headers (browser security restriction). Solutions: (1) Pass auth token as a query parameter: wss://api.example.com/ws?token=abc123 (visible in logs). (2) Send auth message immediately after connecting: {"type":"auth","token":"abc123"}. (3) Use a session cookie set by a prior HTTP request (automatic for same-origin WebSocket). Method 2 (auth message) is most common for security-sensitive applications.
What is a WebSocket subprotocol?
A WebSocket subprotocol is an application-level protocol layered over WebSocket. The client lists supported subprotocols in the Sec-WebSocket-Protocol header; the server selects one. Common subprotocols: STOMP (Simple Text Oriented Message Protocol, used with Spring WebSocket), MQTT over WebSocket (IoT messaging), JSON-RPC over WebSocket. Using a named subprotocol enables libraries like stomp.js or MQTT.js to handle the message framing automatically.
How do I scale WebSockets horizontally?
The challenge: a WebSocket connection is stateful (it's a persistent TCP connection to a specific server). Horizontal scaling requires sticky sessions (load balancer routes the same client to the same server) or a message broker (Redis pub/sub, Apache Kafka) that all server instances subscribe to. Popular solutions: Socket.io with Redis adapter, Ably, Pusher (managed), AWS API Gateway WebSocket API (managed), or nginx with upstream sticky sessions. Serverless WebSocket (AWS, Cloudflare) uses durable objects or external stores.
What happens when a WebSocket connection drops?
The browser fires a 'close' event with a close code and reason. Close codes: 1000 (normal), 1001 (server going away), 1006 (abnormal close, connection lost), 1011 (server error). Good WebSocket clients implement exponential backoff reconnection: first retry after 1 second, then 2, 4, 8, up to a max (e.g., 30 seconds). Libraries like reconnecting-websocket handle this automatically. You should also implement ping/pong heartbeats (the WebSocket spec defines ping/pong frames) to detect silent disconnections.