What Is a WebSocket? Real-Time Two-Way Web Connections

Short answer

A WebSocket is a long-lived, full-duplex connection between a web browser and a server. Unlike regular HTTP (which is request-response — one round trip per interaction), a WebSocket stays open so either side can send data at any time. It's how live chat, multiplayer games, collaborative editors, and real-time dashboards work.

WebSocket vs HTTP — the fundamental difference

	HTTP	WebSocket
Connection lifetime	Per request (or keep-alive within seconds)	Persistent (hours)
Direction	Client initiates every exchange	Both sides send anytime
Overhead	Full HTTP headers on every request	~2-14 bytes per message after handshake
Latency for push	Need polling or SSE	Near-zero
URL scheme	http:// / https://	ws:// / wss://

How the connection is established

1. Client sends an HTTP GET with Upgrade: websocket header.
2. Server responds with HTTP/1.1 101 Switching Protocols.
3. The same TCP connection is now a WebSocket — no more HTTP.
4. Either side can send text or binary frames until one closes.

The 101 response is unusual but valid — look it up in HTTP status codes.

What WebSockets are great for

• Chat and messaging — message appears instantly, no polling
• Collaborative editing — Figma, Google Docs, Notion, every cursor is synced via WebSocket
• Multiplayer games — player positions, game state, hit detection
• Live dashboards — stock tickers, crypto prices, ops monitors
• Notifications — "new message" badges, order updates
• Real-time sensor / IoT feeds — telemetry at high frequency

When NOT to use WebSockets

• One-way server push — Server-Sent Events (SSE) is simpler when only the server sends updates.
• Occasional requests — HTTP + polling every 30 seconds is fine; WebSocket adds complexity.
• CDN cacheability matters — WebSocket responses can't be cached. Stick to HTTP.
• Simple CRUD APIs — classic REST is the right tool.

Authentication over WebSockets

WebSockets don't support custom headers after the handshake, so auth happens in one of three ways:

• Token in the initial upgrade URL — wss://api.example.com/socket?token=abc. Simple but tokens leak into logs.
• Cookie-based — the upgrade request carries cookies; server validates them before accepting.
• Auth message after connect — client's first message is an auth frame; server closes the connection if invalid.

Decode any JWT you're sending over a WebSocket with JWT decoder.

Libraries you'll see

• Socket.IO — adds rooms, namespaces, auto-reconnect, fallback to long-polling. Most popular.
• ws (Node.js) — lightweight, no abstractions
• SockJS — older cross-browser compat layer
• native WebSocket API — in every browser, no library needed for simple cases

Related tools

Pretty-print JSON messages you receive on a WebSocket with JSON formatter. URL-encode query strings on the upgrade URL with URL encoder/decoder.