Skip to main content

Server-Sent Events

Updated 3 min read

Share this page

Send the link, quote the definition with a link back, or show it as a card on your own site.

https://softwaredictionary.org/terms/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-stream data, and browsers read it with the EventSource API.
  • Browsers reconnect automatically and resume using the Last-Event-ID header.
  • 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

A Node.js SSE endpoint and a browser subscriberjavascript
// 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

Spotted a mistake or something missing on this page?Suggest an edit

Read a random page
Open today's review
Switch to the dark theme
Read this page in Türkçe

More

Settings