What is WebSocket — and why a chat updates itself without a page reload

Here's the thing. A regular website lives by the rule "ask — get an answer — connection closes." Every click is a new request, like calling a help desk: ask your question, hang up. Now open any chat or online game: messages show up on their own, no reload. The surprise is that classic HTTP makes this impossible in principle: the server cannot "call" the browser first. Not in any way. WebSocket was invented for exactly this.

How plain HTTP works — and where it hits its limit

The whole web is built on the request–response cycle. The browser asks, the API answers, the connection closes. The initiator is always the client. The server sits and waits: until asked, it stays silent — even if it has urgent news.

So how would you build a chat on pure HTTP? With a crutch: the browser re-asks every second — "anything new? now? now?". That's called polling. It works, but picture a help desk you call once a second, and 99 calls out of 100 get "no, nothing." Traffic burns, the server fends off empty requests, and messages still arrive late.

What WebSocket does

WebSocket changes the model itself. It all starts as a regular HTTP request, but with a special note: "let's switch to WebSocket." The server agrees — and from that moment the connection does not close. An open pipe remains between browser and server, and either side can write into it at any moment.

Not a series of short calls, but one open line: nobody hangs up. A new message arrives — the server pushes it straight into the pipe, the browser receives it and draws it. No reloads, no re-asking, latency measured in milliseconds.

Where you'll meet it

• Chats and messengers — messages land the moment they're sent.
• Online games — player positions sync dozens of times per second.
• Market charts and exchange rates — prices tick without a page refresh.
• Collaborative documents — you see someone else's cursor because edits fly through the open pipe.
• AI voice mode — a real-time conversation with a model streams audio back and forth over WebSocket.

The common trait: data has to arrive on its own, not when you asked.

But ChatGPT types letter by letter — is that WebSocket?

Here's the unexpected part: no. When a model "types" its answer in chunks, that's usually streaming over a single HTTP request: you asked once, and the server hands the answer back piece by piece until it's done. A pipe — but one-way, for one answer.

WebSocket is for when both sides must be able to speak at any moment — like a voice conversation where you can interrupt the model. Remember the distinction: streaming is "a long answer in parts," WebSocket is "an open line both ways."

Do you need WebSocket in your first project?

Most often — no. For an AI chatbot, regular requests with streaming are enough. And if you do need live updates — say, a shared counter or a board for several people — don't build the pipe by hand: ready-made backends like Supabase offer realtime subscriptions with WebSocket already tucked inside. You write "tell me when a row appears in this table" — the service does the rest.

Is WebSocket secure?

Yes — it has an encrypted version, wss://, the same padlock as https://. Every serious service uses it.

How is WebSocket different from a webhook?

A webhook is a one-off HTTP request from a server to another server when an event happens. WebSocket is a persistent line, usually between a server and a browser. A webhook is a call saying "you've got an order"; WebSocket is an open channel.