What Is WebSocket? The Basics Explained

How do chat apps and live price tickers update instantly without ever refreshing the page?

What WebSocket is

Regular HTTP is a request-response protocol: the server can only respond after the client asks for something, so it can never proactively tell the client about new information. WebSocket breaks past that limit, keeping a connection open so that either the server or the client can send a message whenever it needs to, enabling real, two-way, real-time communication.

The problem WebSocket solves: polling

Before WebSocket, sites faked real-time behavior with polling β€” the client repeatedly asking the server 'anything new?' every few seconds. Short polling hammers the server and network with constant requests; long polling improves on it by having the server delay its response until something actually happens, but every request still carries full HTTP header overhead and it's still not truly two-way. WebSocket solves this with one persistent connection instead of endless repeated requests.

The handshake and protocol upgrade

A WebSocket connection starts life as an ordinary HTTP request. The client sends a request with an 'Upgrade: websocket' header, and if the server accepts, it replies with HTTP status code 101 (Switching Protocols). From that moment, the same underlying TCP connection stops behaving like request-response HTTP and becomes a WebSocket connection where either side can send frames at any time.

'ws://' versus 'wss://'

ws:// is an unencrypted WebSocket connection, while wss:// is encrypted with TLS β€” the same relationship as HTTP and HTTPS. Just as with a regular website, always use wss:// for anything sensitive, to prevent eavesdropping or tampering in transit. Most browsers also block an unencrypted ws:// connection attempt from a page loaded over HTTPS, for security reasons.

Real-world use cases

WebSocket (or similar real-time technology) is what powers messages appearing instantly in a chat app without a refresh, live-updating stock and crypto price charts, real-time state syncing in online games, and seeing other people's cursors and edits appear live in a shared document.

WebSocket versus alternative technologies

When you only need the server pushing data to the client β€” not the other way around β€” Server-Sent Events (SSE) can be a simpler alternative, built on plain HTTP and easier to fit into existing infrastructure. But for cases like chat or gaming, where the client also needs to send messages frequently, WebSocket's true two-way communication is the better fit.

Where WebSocket sits alongside HTTP

It's easy to think of WebSocket as something that replaces HTTP, but really it starts as an HTTP request and only switches protocols after a successful handshake (status code 101). That means a WebSocket server still needs to handle an initial HTTP request correctly, and infrastructure that only understands plain HTTP β€” some older proxies or restrictive firewalls β€” can occasionally interfere with the upgrade.

Why production WebSocket apps need extra plumbing

A basic WebSocket connection can silently die β€” a phone switching from Wi-Fi to cellular, a laptop going to sleep β€” without either side immediately noticing, so real applications typically add periodic ping/pong heartbeat frames to detect a dead connection and reconnection logic to recover automatically. Because each WebSocket connection is a long-lived, stateful thing, unlike a stateless HTTP request, scaling a WebSocket service across multiple servers also takes extra care, often using sticky sessions or a shared message broker so a client always reaches the server holding its connection state.

Frequently Asked Questions

Can a firewall block WebSocket connections?

Yes. Some strict corporate networks or public Wi-Fi firewalls block connections or protocol-upgrade requests outside standard HTTP/HTTPS ports (80 and 443). Most WebSocket services minimize this risk by running over port 443, the same port HTTPS normally uses.

Does WebSocket work reliably on mobile?

Connections can drop when switching between Wi-Fi and cellular, or when the screen turns off and the app moves to the background, so real-world WebSocket apps commonly build in automatic reconnection logic to handle exactly this kind of interruption.