A WebSocket is a communication protocol that keeps a connection between a client (such as a browser or app) and a server open, so both sides can send messages to each other at any moment. With normal HTTP, the client has to ask for every update; with a WebSocket, the server pushes new data as soon as it is available. That makes WebSockets the standard for real-time applications: live prices, chat, notifications, dashboards and multiplayer games. The protocol is standardised as RFC 6455 and supported by all modern browsers.
How does a WebSocket work?
- Handshake: the client opens a normal HTTP request with an
Upgrade: websocketheader; the server agrees, and the connection switches protocol. - Persistent connection: the connection stays open over a single TCP connection, using
ws://or, encrypted,wss://. - Full-duplex messages: client and server send text or binary messages in both directions, independently, with very little overhead per message.
- Heartbeats: ping/pong frames check that the connection is still alive.
- Closing: either side can close the connection; clients should reconnect automatically when it drops.
WebSocket vs. polling, SSE and webhooks
- Polling: the client asks every few seconds whether there is news. Simple, but slow and wasteful.
- Server-Sent Events (SSE): the server streams updates over HTTP, but only in one direction. A good choice when the client only needs to listen.
- Webhooks: one server calls another server's URL when an event happens. Suitable for server-to-server notifications, not for live connections to browsers or apps.
- WebSocket: two-way, low latency, ideal when updates are frequent or the client also sends data continuously.
Where WebSockets are used
Trading platforms and crypto exchanges stream prices, order book changes and order updates over WebSockets; most exchange and broker APIs offer a WebSocket feed next to their REST API. Other typical uses are chat and support tools, live dashboards for logistics or production, collaborative editing, notifications and GraphQL subscriptions.
What to watch out for
Thousands of open connections need a server that handles many concurrent connections efficiently, and load balancers and proxies must be configured to pass WebSocket traffic and keep connections open. Clients need reconnection logic with backoff, and after a reconnect they must catch up on messages they missed. Authentication is usually done at the handshake, for example with a token. See our WebSocket development and real-time dashboards.
Frequently Asked Questions about WebSockets
Is a WebSocket the same as HTTP?
No. A WebSocket connection starts as an HTTP request, but after the handshake it switches to its own protocol, with a persistent two-way connection.
Are WebSockets secure?
With wss://, traffic is encrypted with TLS, just like HTTPS. The server still has to authenticate users, check the origin of connections and validate every incoming message.
How many WebSocket connections can a server handle?
That depends on the server software and the message volume. Well-built asynchronous servers handle tens of thousands of open connections per machine, and more with horizontal scaling.
When should I not use WebSockets?
When updates are rare, when the client only needs to listen (SSE is simpler), or for server-to-server notifications (webhooks are a better fit).