Server-Sent Events
In short
Server-Sent Events is a web standard that lets a server push a continuous stream of text updates to the browser over one long-lived HTTP connection.
What are Server-Sent Events?
Server-Sent Events, or SSE, give a web page a one-way channel from the server: the browser opens a connection once, and the server keeps it open and sends a new message whenever it has something to report. SSE is built into browsers through the EventSource API and runs over ordinary HTTP, so it passes through most proxies, load balancers, and firewalls without special setup.
The server responds with the content type text/event-stream and writes messages in a simple text format: lines starting with data:, optionally event: for a named event type and id: for a message ID, with a blank line ending each message. If the connection drops, the browser reconnects automatically and sends a Last-Event-ID header, so the server can resume where it left off. Over HTTP/1.1, browsers allow only about six open connections per site, which can be a problem with many tabs, but over HTTP/2 and HTTP/3 many streams share a single connection.
SSE is like tuning in to a live news ticker: you subscribe once and headlines keep arriving, but you can't talk back on the same channel. It is a natural fit for notifications, live dashboards, stock prices, build and deployment logs, progress bars, and streaming responses from LLMs, where text appears word by word as the model generates it. When the client needs to send data, it uses ordinary HTTP requests alongside the stream.
SSE is often compared with WebSocket and long polling. WebSocket is a separate, two-way protocol where both sides can send messages at any time, which suits chat, multiplayer games, and collaborative editing but needs more infrastructure support. Long polling imitates push with repeated requests that the server holds open until data arrives, and the client must reconnect after every response. SSE sits in between: one-way server push, text only, with automatic reconnection over plain HTTP. One limitation is that the native EventSource can't send custom headers such as Authorization, so apps rely on cookies or use a fetch()-based SSE client instead.
Key takeaways
- SSE streams messages from server to browser over one long-lived HTTP response.
- The server sends
text/event-streamdata, and browsers read it with theEventSourceAPI. - Browsers reconnect automatically and resume using the
Last-Event-IDheader. - SSE is one-way and text-only; use WebSocket when both sides need to send messages.
- It is widely used for notifications, live dashboards, and streaming LLM output.
Example
// Server (Node.js): keep the response open and write events
import http from "node:http";
http.createServer((req, res) => {
res.writeHead(200, { "Content-Type": "text/event-stream", "Cache-Control": "no-cache" });
const timer = setInterval(() => {
res.write("data: " + JSON.stringify({ time: Date.now() }) + "\n\n");
}, 1000);
req.on("close", () => clearInterval(timer));
}).listen(3000);
// Browser: subscribe and react to each message
const source = new EventSource("/events");
source.onmessage = (event) => console.log(JSON.parse(event.data).time);Readers ask
Is SSE better than WebSocket?
Neither is better overall. SSE is simpler and works over plain HTTP with automatic reconnection, which makes it ideal when only the server needs to push data; WebSocket is the better choice when both sides send frequent messages, such as in chat or games.
Why do LLM APIs use Server-Sent Events?
They stream generated text piece by piece, so users see the answer appear immediately instead of waiting for the whole response. SSE fits this one-way stream well and works with ordinary HTTP infrastructure.
Does SSE work with HTTP/2?
Yes, and it works better there. HTTP/2 multiplexes many streams over one connection, which removes the HTTP/1.1 limit of about six connections per site that could block SSE across many tabs.
Often compared
See also
- WebSocketWeb Development, p. 61WebSocket is a protocol that keeps a single connection open between a browser and a server so both sides can send each other messages instantly at any time.
- Long PollingBackend & APIs, p. 28Long polling is a technique where a client sends a request that the server holds open until new data is ready, imitating real-time push over plain HTTP.
- HTTPWeb Development, p. 19HTTP is the protocol that browsers, apps, and servers use to exchange web pages and data through a simple cycle of requests and responses.
- Pub/SubBackend & APIs, p. 35Pub/sub is a messaging pattern where publishers send messages to topics and every subscriber to a topic gets a copy, without either side knowing the other.
- Event StreamingBackend & APIs, p. 14Event streaming is the practice of recording events as a continuous, ordered and durable log that many applications can read, replay and process in real time.
- LLMAI & Machine Learning, p. 25An LLM is a machine learning model trained on huge amounts of text that generates language by repeatedly predicting the next most likely piece of text.
Spotted a mistake or something missing on this page?Suggest an edit