Server-Sent Events
Server-Sent Events stream text updates from server to browser over one long-lived HTTP response, with automatic reconnection and last-event replay built in.
Definition
Server-Sent Events is a browser API and wire format where the server holds an HTTP response open and writes text/event-stream messages, giving clients a one-way stream of events over ordinary HTTP.
Context and scope
Use it for dashboards, notifications, logs, and progress updates where the client only needs to listen, not send messages back.
Common misconceptions
- SSE is the same as WebSockets; SSE is one-way and text-only, while WebSockets are bidirectional
- Any HTTP server streams events without configuration; buffering proxies and compression can delay messages
- Disconnects always lose data; the id field plus Last-Event-ID enables replay when the server keeps history
Anti-patterns
- Sending unbounded events to slow consumers without backpressure or a queue limit
- Omitting the id field so reconnects cannot resume where they stopped
- Using SSE for high-frequency binary or low-latency input, where WebSockets fit better
Related concepts
Related examples
Authoritative source
https://html.spec.whatwg.org/multipage/server-sent-events.html
How it works
The client opens a normal HTTP request with Accept: text/event-stream. The server responds with that content type and keeps the body open, writing small UTF-8 messages separated by blank lines. Each message can carry event, id, retry, and data fields. The browser parses them and dispatches events to the page.
HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
id: 1041
event: price
data: {"symbol":"ETH","usd":3120.44}If the connection drops, EventSource reconnects automatically after the retry interval and sends Last-Event-ID: 1041, letting the server replay missed events. Proxies must not buffer the response; disabling compression or flushing per event is often required.
When to use it
SSE fits one-way, text-friendly streams: live dashboards, notification bells, build logs, LLM token output, and progress indicators. It is simpler than WebSockets because it uses plain HTTP, works with cookies and standard auth, and reconnects without custom code. It is a poor fit when the client must also send frequent messages or exchange binary data.
Trade-offs
Each open stream consumes a connection and server-side resources. Over HTTP/1.1 browsers limit connections per domain, so many tabs can starve other requests; HTTP/2 largely removes that limit. A slow client can accumulate a backlog, so servers need bounded queues and a policy for dropping or disconnecting laggards. Replay only works if event ids and a retention window exist.
Example and misconceptions
A frequent misunderstanding is that SSE replaces WebSockets. For a chat app where users type continuously, WebSockets remain the better tool. For a read-only price ticker, SSE needs far less code.
Related concepts: Long Polling, Backpressure, and Webhooks.