WebSocket Debug Console

WebSocket is a full-duplex communication protocol over a single TCP connection. Unlike HTTP (request-response), WebSocket keeps the connection open, allowing both client and server to send messages at any time with minimal overhead (~2-10 bytes per frame vs ~500-800 bytes of HTTP headers). It starts with an HTTP handshake (the 'Upgrade' request), then upgrades to the WebSocket protocol. Use WebSocket for real-time features: live chat, gaming, collaborative editing, market data feeds, and live notifications.

ws:// is unencrypted WebSocket (analogous to HTTP). wss:// is WebSocket Secure — encrypted with TLS (analogous to HTTPS). Always use wss:// in production for security. Modern browsers block mixed content: if your page is served over HTTPS, it will refuse to open ws:// connections. During local development, ws://localhost is allowed even from HTTPS pages in most browsers.

Ping and Pong are control frames built into the WebSocket protocol (RFC 6455). A ping frame can be sent by either party; the recipient must respond with a pong containing the same payload. They serve as a heartbeat to detect dead connections and prevent idle timeout disconnects from proxies. The browser's WebSocket API does not expose ping/pong frames to JavaScript — the browser handles them automatically. Server-side, most libraries expose ping/pong APIs (e.g., ws.ping() in Node.js). This tool sends a JSON ping message as a proxy when in real-server mode.

WebSocket is not subject to the same-origin policy by design — any origin can initiate a WebSocket connection to any server. However, the server receives the Origin header in the HTTP upgrade request and should validate it server-side. Most frameworks check this automatically. This means you can connect to wss://echo.websocket.events from any origin, but production servers should whitelist allowed origins to prevent cross-site WebSocket hijacking (CSWSH).

1. Exponential backoff: start with 1s delay, double each attempt (2s, 4s, 8s...) with jitter to prevent thundering herd. 2. Max retries: stop after N attempts and show an error to the user. 3. Visibility-aware: pause reconnection when the tab is backgrounded (document.hidden). 4. Online/offline: listen to navigator.onLine and window online/offline events. 5. Close code check: only auto-reconnect on unexpected closes (code !== 1000, 1001). Libraries like reconnecting-websocket implement all of these patterns.

Open DevTools → Network tab → filter by 'WS'. Click a WebSocket connection to see: the Headers tab (handshake request/response), and the Messages tab (all frames with timestamps, direction, and payload). For binary frames, you'll see the raw bytes. You can also use the Console: const ws = new WebSocket('wss://...'); ws.onmessage = e => console.log(e.data);. The Performance panel can show WebSocket frame timing in the network track.