Suppose you are building a live dashboard. The server needs to push updates whenever a job finishes, a metric changes, or a new alert appears, but the browser does not need to send messages back over the same connection.

WebSockets work, but full bidirectional messaging may be more complexity than you need. Long polling works, but every response closes the request and forces the client to reconnect.

Server-Sent Events (SSE) sit between those two. The browser opens one connection and the server streams text events over a single long-lived HTTP response.

This chapter covers what SSE provides and what it does not, how the event stream format works, how browser reconnection and Last-Event-ID work, how to implement SSE safely on the server, and when to choose SSE instead of long polling or WebSockets.

SSE is a browser API and wire format for one-way server-to-client streaming.

SSE is one-way (events flow from server to browser) and HTTP-based (the stream is a long-lived HTTP response). Payloads are UTF-8 text, often JSON strings, and each event is a distinct message rather than a byte stream. Browsers reconnect automatically after most disconnects and send the Last-Event-ID header on reconnect if the stream provided event IDs.

SSE is a good fit for notifications, activity feeds, dashboard updates, progress updates, build logs, status changes, and other server-authored event streams.

It is not a replacement for WebSockets when the browser needs to send frequent messages on the same connection. It is also not a media protocol; use WebRTC, HLS, or DASH for audio and video.