A WebSocket is a communication protocol that holds a connection open between a browser and a server so that data can flow in both directions at any time, without the page needing to ask for it. It's the technology behind live chat applications, real-time sports scores, financial tickers, and collaborative tools like shared documents. If you've ever watched a number update on screen the moment something changes, there's a good chance a WebSocket made that happen.
Why ordinary HTTP isn't enough
Standard web browsing runs on HTTP, a request-response model. Your browser asks for something, the server sends it back, and the connection closes. That's fine for loading a news article. It's not fine for a live trading dashboard where prices change 40 times a second.
Before WebSockets became widespread, developers worked around HTTP's limitations using techniques like polling, where the browser re-asks the server every few seconds whether anything new has happened. Polling works, barely. It's wasteful, slow, and burns through bandwidth because most of those requests come back empty. Long-polling was a slight improvement, holding the request open until the server had something to say, then immediately closing it again. Still messy.
WebSockets solve the problem directly. One connection. Stays open. Both sides talk whenever they want.
How a WebSocket connection is established
The process starts with what's called a handshake. The browser sends a normal HTTP request, but with a special header: Upgrade: websocket. The server reads that header and, if it supports WebSockets, responds with a 101 status code, meaning "Switching Protocols". From that point on, the HTTP connection transforms into a WebSocket connection.
The whole handshake takes one round trip. Once it's done, both the browser and the server hold an open channel. Either side can push a message at any moment. The server doesn't wait for the browser to ask. The browser doesn't need to keep polling. It's a persistent, full-duplex channel, meaning data travels both ways simultaneously, like a phone call rather than a series of text messages.
WebSockets operate over port 80 for unencrypted connections (ws://) and port 443 for encrypted ones (wss://). In practice, almost all production WebSocket connections use wss:// for the same reason websites use HTTPS: it encrypts the data in transit.
What WebSockets are used for
The clearest use cases are anything where the data on screen needs to reflect the real world with minimal delay. Live chat is the textbook example. When you send a message on Slack or a live support widget, a WebSocket carries it to the server and the server pushes it to every connected recipient instantly.
Financial platforms depend on WebSockets heavily. A foreign exchange desk can't have prices that are three seconds stale. The Socket.IO library, one of the most widely used WebSocket tools in Node.js development, was built largely for exactly these kinds of persistent, event-driven connections.
Multiplayer browser games use WebSockets to sync player positions. Collaborative editors, like tools that let two people edit the same document at once, use WebSockets to broadcast each keystroke. Online auctions, live dashboards, and real-time notifications all rely on the same underlying protocol.
It's also worth understanding what WebSockets don't replace. They're not the right tool for a standard page load, a form submission, or a file download. Those are request-response jobs, and HTTP handles them cleanly. Understanding the difference matters because pairing the wrong tool with a job adds complexity for no gain. For more on how servers manage and distribute these kinds of connections at scale, the concept of load balancing becomes important, since a WebSocket connection is long-lived and can't simply be re-routed the way a short HTTP request can.
How WebSocket messages are structured
Data sent over a WebSocket travels in frames. A frame is a small unit of data with a header describing its type and length, followed by the payload. Frames can carry text (usually JSON) or binary data like images or audio streams.
The protocol itself doesn't dictate what format your messages take. That's up to the application. Most web developers send JSON objects. A chat message might look like {"user": "alex", "text": "Hey", "timestamp": 1728399600}. The server receives it, parses it, and decides what to do.
There are also control frames: ping, pong, and close. The server can send a ping frame to check whether the client is still connected. The client responds with a pong. If no response comes, the server knows the connection has dropped and can clean it up. The close frame is how either side signals a graceful shutdown.
Security considerations
WebSockets inherit some of HTTP's security model but not all of it. The same-origin policy that browsers enforce for regular HTTP requests doesn't automatically apply to WebSocket connections in the same strict way. A server needs to explicitly check the Origin header on the incoming handshake request and reject connections from origins it doesn't trust. Skipping that check is a real vulnerability.
Authentication is also the developer's responsibility. A WebSocket connection doesn't carry cookies or session tokens by default after the handshake. Developers typically pass a token as a query parameter during the upgrade request or negotiate authentication in the first message after connecting. Neither approach is perfect, and getting it wrong exposes the connection to unauthorised access.
Using wss:// rather than ws:// is non-negotiable in production. An unencrypted WebSocket connection sends everything in plaintext, making it trivially readable to anyone positioned between the client and the server. Paired with a solid understanding of how encryption protects data in transit, the case for always using wss:// is straightforward.
WebSockets versus alternatives
Two technologies often come up alongside WebSockets: Server-Sent Events (SSE) and HTTP/2 push. SSE is simpler and lets the server push updates to the browser, but it's one-directional. The browser can't send data back over the same channel. For read-only dashboards or notification feeds, SSE is lighter and easier to implement. For anything that needs two-way communication, WebSockets are the right choice.
HTTP/2 push was supposed to let servers proactively send resources to browsers before they were requested, but the feature was deprecated in major browsers by 2023 due to poor adoption. It was never really a WebSocket competitor anyway: it targeted asset delivery, not event-driven messaging.
The WebSocket protocol itself is defined in RFC 6455, published by the Internet Engineering Task Force. Most modern browsers and server environments have supported it natively since around 2012. It's not a new technology. It's a mature, stable one that quietly powers a large share of the interactive web.
A brief note on scaling
Each open WebSocket connection holds resources on the server. A single server can handle thousands of simultaneous connections, but not infinitely many. At scale, engineering teams use message brokers like Redis or Apache Kafka to distribute WebSocket messages across multiple server instances, so that a message from one connected client reaches all other clients even if they're connected to a different machine. This is where infrastructure design intersects with the protocol itself.
WebSockets changed what the web could do. Before them, real-time was a hack. After them, it became a first-class feature of the platform.