WebSockets: Browser Support, Use Cases, Limitations

What are WebSockets?

WebSockets is a protocol that opens a single, persistent TCP connection and lets a browser and a server push messages to each other at any time without polling. The IETF standardized it as RFC 6455, and the WebSocket JavaScript interface is defined by the WHATWG HTML Living Standard.

Which browsers support WebSockets?

WebSockets ship in every modern browser, with global support near 99% across desktop and mobile. The protocol has been stable since the IETF published RFC 6455, so once a browser shipped it, the WebSocket interface has not broken across versions.

How do WebSockets work?

WebSockets work by upgrading an HTTP connection to a long-lived TCP socket and then exchanging framed messages in both directions. The handshake and the message loop follow these steps:

• Open a WebSocket from the browser: Call new WebSocket("wss://example.com/socket") with an optional list of subprotocols. The constructor returns immediately with the socket in the CONNECTING state.
• Send the HTTP Upgrade request: The browser sends an HTTP/1.1 GET request that carries Upgrade: websocket, Connection: Upgrade, a random Sec-WebSocket-Key, and the protocol version Sec-WebSocket-Version: 13.
• Receive the 101 Switching Protocols response: The server replies with a 101 status, a Sec-WebSocket-Accept header derived from the client key, and any subprotocol it picked from the request list.
• Switch to the WebSocket frame protocol: Both sides now treat the same TCP socket as a stream of binary or text frames. Each frame carries an opcode, a payload length, an optional mask, and the payload bytes - no further HTTP headers.
• Exchange messages in either direction: Either side can send a frame at any time. The browser fires the message event on receive, and the page calls socket.send to push data back. Ping and pong frames keep the connection alive across idle proxies.
• Close the connection cleanly: Either side sends a close frame with a status code and an optional reason. The browser fires the close event with the same code, and the underlying TCP socket tears down.

The wss:// scheme runs the same protocol over TLS on port 443, which lets the connection traverse most corporate proxies and firewalls without extra configuration. Paste this snippet into the DevTools console of Chrome, Edge, Firefox, or Safari to confirm WebSocket support and watch a frame round-trip through a public echo server.

// Paste this into the DevTools console to confirm WebSocket support and open a test connection.
if ("WebSocket" in window) {
  console.log("WebSocket is supported in this browser.");

  const socket = new WebSocket("wss://echo.websocket.events");

  socket.addEventListener("open", () => {
    console.log("Connection opened, sending a test frame.");
    socket.send("hello from TestMu AI");
  });

  socket.addEventListener("message", (event) => {
    console.log("Echo received:", event.data);
    socket.close();
  });

  socket.addEventListener("close", (event) => {
    console.log("Connection closed with code", event.code);
  });

  socket.addEventListener("error", () => {
    console.log("WebSocket error: the echo server may be unreachable from this network.");
  });
} else {
  console.log("WebSocket is not supported in this browser.");
}

What are the use cases of WebSockets?

WebSockets fit any product that needs server-pushed updates faster than HTTP polling can deliver, with a roundtrip cost low enough for sub-second user feedback. The pattern that locks teams into WebSockets is bidirectional traffic, where both client and server initiate messages.

• Chat and team messaging: Slack, Discord, and most live-chat widgets use WebSockets to push new messages, presence updates, typing indicators, and reactions. The persistent socket avoids the latency and battery cost of long polling on mobile clients.
• Collaborative editors: Google Docs, Figma, Notion, and Linear stream document operations through WebSockets. The protocol carries operational transforms and conflict-free replicated data type updates with sub-100-millisecond latency between collaborators.
• Live dashboards and trading: TradingView and most fintech dashboards stream price ticks, order book updates, and chart candles over WebSockets. Fan-out from one server to thousands of subscribers is a fixed cost per message instead of a per-poll cost.
• Multiplayer games and live sports: Browser-based games and live scoreboards push state updates over WebSockets. The 30 to 60 frames-per-second update floor that competitive games need is only practical with a persistent connection.
• IoT control panels: Home Assistant, AWS IoT, and Azure IoT Hub web consoles use WebSockets to send device state to the page and accept user commands back to the device without polling each sensor.

What are the limitations of WebSockets?

WebSockets buy real-time delivery at the cost of a long-lived connection that traditional HTTP infrastructure does not always handle cleanly. The painful failures cluster around proxies, load balancing, scaling, and HTTP/2 multiplexing.

• Corporate proxies drop idle sockets: Many corporate forward proxies close TCP connections after 30 to 60 seconds of silence and never forward the WebSocket Upgrade. Send ping frames every 20 seconds and fall back to HTTP long polling for users behind strict firewalls.
• Load balancers need sticky sessions: Round-robin load balancing breaks WebSockets because every frame after the handshake must reach the same backend. AWS Elastic Load Balancer, NGINX, and HAProxy all need session affinity or a dedicated WebSocket-aware setup.
• No built-in reconnection: The browser does not retry a dropped connection, so the page must implement exponential backoff, queue replay, and last-event ID logic. Libraries like Socket.IO and Ably wrap this, but native WebSocket code has to write it.
• Per-connection memory cost: A single idle WebSocket holds about 50 to 130 KB of server memory between TCP buffers, the WebSocket library object, and the application session. One million concurrent connections costs around 100 GB of RAM, so plan capacity early.
• HTTP/2 and HTTP/3 multiplexing is patchy: RFC 8441 added a CONNECT-style WebSocket bootstrap over HTTP/2, but adoption is patchy and many CDNs still tunnel WebSockets over HTTP/1.1. The result is one TCP connection per WebSocket per origin instead of multiplexed streams.
• Limited browser observability: Chrome DevTools shows WebSocket frames in the Network tab, but Firefox DevTools and Safari Web Inspector only surface the handshake. Production debugging usually relies on server-side logs and a Wireshark capture.

In my experience, the limitation that bites teams hardest is the proxy timeout. A real-time feature that works perfectly on home Wi-Fi falls silent on a hotel network because the proxy closes the socket after 60 seconds and the client never reconnects until the user refreshes the page. Wire ping frames and an exponential-backoff reconnect handler before you ship.

Citations

All WebSocket version numbers and platform notes in this guide come from these primary sources:

• MDN Web Docs - WebSockets API: developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
• MDN Web Docs - WebSocket interface: developer.mozilla.org/en-US/docs/Web/API/WebSocket
• IETF RFC 6455 - The WebSocket Protocol: datatracker.ietf.org/doc/html/rfc6455
• IETF RFC 8441 - Bootstrapping WebSockets with HTTP/2: datatracker.ietf.org/doc/html/rfc8441
• WHATWG HTML Living Standard - Web Sockets: html.spec.whatwg.org/multipage/web-sockets.html
• Wikipedia - WebSocket: en.wikipedia.org/wiki/WebSocket
• Chrome for Developers - WebSocketStream: developer.chrome.com/docs/capabilities/web-apis/websocketstream
• Chrome Platform Status - WebSocket: chromestatus.com/feature/6121223957184512
• Mozilla Hacks - WebSockets in Firefox: hacks.mozilla.org/2011/03/websockets-in-firefox-4
• Microsoft Learn - WebSockets in Internet Explorer: learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/dev-guides/hh673567