Server-Sent Events (SSE) is a web standard that enables a server to push real-time updates to a browser over a single, long-lived HTTP connection. It is a lightweight alternative to WebSockets for scenarios where data flows only from server to client.
Server-Sent Events is a part of the HTML5 specification that allows a web server to stream text-based events to a browser client over a persistent HTTP connection. The browser uses the built-in EventSource API to open this connection and receive updates. Unlike WebSockets, SSE is strictly unidirectional — data flows only from server to client. This makes it ideal for use cases like live feeds, notifications, dashboards, and AI chat streaming.
SSE solves the real-time update problem without the complexity of WebSockets or the inefficiency of polling. Because SSE uses plain HTTP/1.1 or HTTP/2, it works seamlessly through existing infrastructure like load balancers, proxies, and firewalls that may block WebSocket upgrades. The browser also handles automatic reconnection natively, reducing the amount of client-side code you need to write. For one-way streaming scenarios, SSE is often simpler, cheaper to implement, and easier to debug than WebSockets.
The client opens a connection using the EventSource API: const es = new EventSource('/events'). The server responds with the Content-Type header set to text/event-stream and keeps the connection open indefinitely. Data is sent as plain text frames following the format 'data: <payload>\n\n', with optional fields like event (custom event name), id (last-event-ID for reconnection), and retry (reconnect delay in milliseconds). Each message is delimited by a blank line, and the browser fires a message or named event on the EventSource object when a frame arrives.
One of SSE's most powerful built-in features is automatic reconnection: if the connection drops, the browser waits for the retry interval (default ~3 seconds) and reconnects automatically. When reconnecting, the browser sends a Last-Event-ID HTTP header containing the id of the last event it successfully received. The server can use this value to replay missed events, enabling reliable delivery without extra client logic. Setting meaningful id values on every event is therefore a critical best practice for production SSE streams.
WebSockets provide full-duplex, bidirectional communication over a single persistent TCP connection, making them suitable for chat applications, multiplayer games, and collaborative editors. SSE, by contrast, is simpler to implement on both the server and client when you only need server-to-client data flow. SSE also benefits from native HTTP/2 multiplexing, allowing hundreds of SSE streams to share a single TCP connection with no additional configuration. Choose WebSockets when the client must also send frequent streaming data; choose SSE when the server is the primary data source.
SSE connections count against browser per-origin connection limits — HTTP/1.1 browsers allow only 6 connections per origin, so avoid opening many EventSource instances from the same page; HTTP/2 largely eliminates this concern. Always set appropriate Cache-Control: no-cache headers to prevent proxies from buffering the stream. On the server, make sure to flush the response buffer after each event write, since many frameworks buffer output by default. Finally, implement server-side heartbeat events (e.g., a comment line ':ping\n\n' every 15–30 seconds) to prevent idle connection timeouts imposed by load balancers or proxies.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app