Programming · Web · Networking
What is a WebSocket?
Most of the web works by request and response: the browser asks, the server answers, the connection closes. That is fine for loading a page, but it falls apart when you want live updates — a chat message, a stock tick, a multiplayer move — that the server needs to push the moment they happen. A WebSocket is the standard answer. This guide explains what a WebSocket is, how it differs from ordinary HTTP, and when you actually need one.
The core idea: one connection, both directions
A WebSocket is a persistent, two-way (full-duplex) connection between a client — usually a browser — and a server. Once it is open, either side can send a message at any time, without the other side having to ask first. That is the key difference from a normal HTTP API: HTTP is one request, one response, then done; a WebSocket stays open and carries messages in both directions for as long as you need it.
Because the connection is already open, messages arrive with very little overhead and almost no delay. There are no repeated headers, no new handshake per message — just a small frame of data each way. That is what makes WebSockets suited to anything that has to feel instant.
How a WebSocket starts: the HTTP handshake
A WebSocket does not appear from nowhere — it begins as an ordinary HTTP request. The browser sends a normal request with an Upgrade: websocket header, essentially asking the server to switch protocols. If the server agrees, it replies with status 101 Switching Protocols, and from that point on the same TCP connection stops speaking HTTP and starts speaking the WebSocket protocol. This is why WebSockets travel over the same ports as the web (80 and 443) and pass through most firewalls that already allow web traffic.
After the handshake, data moves as lightweight frames. Each message can be text — very often JSON — or binary, and there is no fixed request/response shape: messages simply flow when there is something to send.
ws vs wss
WebSocket URLs use their own scheme. ws:// is an unencrypted connection, and wss:// is the encrypted version, secured with TLS exactly the way https:// is. In practice you should always use wss:// in production — it is encrypted, and it is far less likely to be blocked by proxies and corporate networks that mistrust plain ws:// traffic.
WebSocket object, then listen for messages as they arrive.When to use a WebSocket (and when not to)
WebSockets shine whenever the server has to push data to the client as it happens:
- Chat and messaging — messages appear the instant they are sent.
- Live dashboards and prices — stock tickers, metrics, sports scores.
- Collaboration — shared documents and whiteboards where edits sync live.
- Multiplayer games — low-latency state updates in both directions.
- Notifications — anything the user should see without refreshing.
They are not the right tool for everything. If the client only ever asks and the server only ever answers — loading a page, submitting a form, fetching a record — a plain HTTP API is simpler, cacheable and easier to scale. Reach for a WebSocket when the server needs to start the conversation.
WebSockets vs polling vs SSE
Before WebSockets, the usual trick for "live" data was polling: the client asks the server "anything new?" every few seconds. It works, but it is wasteful — most requests come back empty, and updates still lag by the polling interval. A WebSocket replaces all of that with one open connection and zero wasted requests.
There is also Server-Sent Events (SSE), which gives you a one-way stream from server to client over plain HTTP. SSE is simpler when you only need the server to push (a news feed, a progress bar). Choose a WebSocket when you need messages to flow both ways, and SSE when one direction is enough.
A note on infrastructure
Because a WebSocket holds a connection open, it changes how you deploy. Long-lived connections need a server and a reverse proxy configured to keep them alive rather than time them out, and scaling many simultaneous connections is its own design problem. That is the trade-off: a WebSocket buys you instant, two-way communication in exchange for holding state open on the server.
The bottom line
A WebSocket is a single, persistent, two-way connection that lets the server and browser exchange messages the moment they happen — without the ask-and-wait rhythm of HTTP. It starts life as an HTTP request that is upgraded, then carries lightweight frames in both directions. Use wss://, reach for it when the server needs to push live data, and stick with a normal HTTP API when a simple request and response will do.