Server-Sent Events vs WebSockets for AI Chat Apps
6 min read · Updated Aug 5, 2026
Server-Sent Events (SSE) is a one-way stream from server to browser over plain HTTP, and it is the right default for streaming an LLM’s response token by token, since a chat reply only ever flows one direction until the user sends their next message. WebSockets add a full-duplex, bidirectional connection, worth the extra complexity only when the client also needs to push data to the server continuously mid-stream, like a live voice conversation or a collaborative multi-user chat, not a typical request-then-stream-response chat UI.
Key takeaways
- SSE runs on plain HTTP: a
text/event-streamresponse the browser’sEventSourceAPI (or a manual fetch reader) consumes incrementally, no special server infra beyond keeping the connection open. - WebSockets require a protocol upgrade handshake and a persistent bidirectional socket, more moving parts and more infra (sticky sessions or a pub/sub layer behind a load balancer) for a capability most chat UIs never use.
- Nearly every major AI provider’s streaming API (OpenAI, Anthropic) is already SSE-shaped under the hood, so building the front end on SSE matches how the upstream API already streams.
- SSE reconnects automatically via the browser’s
EventSourceAPI with aLast-Event-IDheader. WebSockets need you to build reconnection logic yourself from scratch. - SSE is capped by the browser’s per-domain HTTP/1.1 connection limit, six in most browsers, and cannot push binary data efficiently. WebSockets do not share that limit and handle binary natively.
What each one actually is
SSE is a regular HTTP response that never closes. The server sets Content-Type: text/event-stream and writes small data: ... chunks as they become available, the browser’s built-in EventSource API (or your own fetch reader) parses them as they arrive. There is no handshake beyond the normal HTTP request, and the browser handles reconnection automatically if the connection drops. A WebSocket starts as an HTTP request too, but immediately upgrades to a completely different protocol: a raw, persistent, bidirectional socket where either side can send a message at any time, with no built-in request/response shape at all.
const response = await fetch('/api/chat/stream', {
method: 'POST',
body: JSON.stringify({ prompt: userMessage }),
});
const reader = response.body.getReader();
const decoder = new TextDecoder();
let fullText = '';
while (true) {
const { done, value } = await reader.read();
if (done) break;
const chunk = decoder.decode(value);
const lines = chunk.split('\n').filter((l) => l.startsWith('data: '));
for (const line of lines) {
const token = line.replace('data: ', '');
if (token === '[DONE]') continue;
fullText += token;
renderPartialResponse(fullText);
}
}Why SSE is the default for LLM streaming specifically
OpenAI’s and Anthropic’s streaming completion endpoints already return their tokens as an SSE stream. Your backend proxies that stream (adding auth, logging, rate limiting) and your front end consumes it the same way. Reaching for a WebSocket here means converting an already-one-directional stream into a bidirectional protocol for no functional gain, then building the plumbing to keep that socket alive, authenticated, and reconnecting cleanly on your own.
When WebSockets are actually worth it
A WebSocket earns its complexity when the client genuinely needs to send data continuously while the server is also streaming back, not just click a button between requests. A live voice mode where audio frames stream up while a response streams down at the same time is a real case. A collaborative multi-user chat where several people’s messages need to interleave in real time on everyone’s screen is another. So is letting a user interrupt ("barge in on") a response mid-generation with genuinely low latency, since a WebSocket avoids the overhead of starting a fresh HTTP request for the interrupt signal. A single user sending one message and reading one streamed reply is not that case, no matter how "real-time" it feels in a pitch deck.
Side by side
| Factor | SSE | WebSockets |
|---|---|---|
| Direction | Server to client only | Bidirectional |
| Built on | Plain HTTP | Protocol upgrade to a raw socket |
| Reconnection | Automatic, built into EventSource | You implement it yourself |
| Infra complexity | Low, works with standard HTTP load balancing | Higher, often needs sticky sessions or a pub/sub layer |
| Binary data | Text only, natively | Native binary support |
| Matches upstream LLM APIs | Yes, OpenAI and Anthropic stream as SSE | No, requires converting a one-way stream |
The Tuesday deploy that dropped 200 conversations
In late 2023, I built the streaming layer for a client’s chat product on WebSockets, mostly because it sounded like the more "real-time" engineering choice for a chat product. Three weeks in, we hit a wall that had nothing to do with streaming itself: the WebSocket server needed sticky sessions behind the load balancer, and our infra was not set up for that cleanly. A routine deploy on a Tuesday afternoon rotated the backend pods mid-conversation and dropped every open socket at once, roughly 200 users lost their in-progress response with no warning. We rewrote the streaming layer to SSE that same weekend. Deploys stopped killing active chats, because a fresh SSE connection just reconnects on its own, and nothing about the design ever assumed a specific server instance had to stay in place.
My honest take: default to SSE for any LLM chat UI, and only reach for WebSockets when you can name a concrete bidirectional requirement. The word "real-time" does a lot of unearned work in these conversations. A one-way token stream over SSE feels exactly as real-time to a user as the same stream over a WebSocket, they cannot tell the difference from the interface. Your team can absolutely tell the difference in on-call complexity the first time a deploy needs to happen mid-conversation.
“The user cannot tell whether your tokens arrived over SSE or a WebSocket. Your on-call rotation can.”
Frequently asked questions
Frequently asked questions
Is SSE or WebSockets better for streaming ChatGPT-style responses?
SSE, for the vast majority of chat UIs. It matches the one-directional shape of a streamed response, requires far less infrastructure, and lines up with how OpenAI and Anthropic already stream their own APIs.
Does OpenAI’s API use SSE or WebSockets?
OpenAI’s streaming chat completions endpoint returns a Server-Sent Events stream. OpenAI’s separate Realtime API for voice does use WebSockets, since that use case is genuinely bidirectional.
Can SSE handle binary data?
Not efficiently. SSE is a text-based protocol built for streaming text data like tokens. If you need to stream binary data, such as audio, a WebSocket handles that natively without extra encoding overhead.
Does SSE reconnect automatically if the connection drops?
Yes. The browser’s built-in EventSource API reconnects automatically and sends a Last-Event-ID header so the server can resume from where the stream left off, without any custom reconnection code on your part.
When should I use WebSockets instead of SSE for an AI chat app?
When the client genuinely needs to send data continuously while the server streams back, such as a live voice conversation, a collaborative multi-user chat, or low-latency mid-generation interruption. A standard one-user, one-reply chat interface does not need it.
What is the six-connection browser limit and does it affect SSE?
Browsers cap concurrent HTTP/1.1 connections at six per domain, which can stall additional SSE streams if a user has many tabs open on the same site. Serving the endpoint over HTTP/2, which multiplexes many streams over one connection, removes this limit without any client-side changes.