How Server-Sent Events Work
BeginnerServer-Sent Events (SSE) let a server push a continuous stream of updates to a browser over a single, long-lived HTTP connection. Unlike WebSockets, SSE is one-way (server to client only) and rides on plain HTTP, which makes it simple to build and firewall-friendly. The browser EventSource API handles the connection, parses the text/event-stream format, and automatically reconnects if the connection drops — ideal for notifications, live feeds, and progress updates.
Think of subscribing to a live news ticker
SSE is like a news ticker that streams headlines to your screen one after another over a single open line — you just watch as updates arrive. You cannot talk back through the ticker (it is one-way), but you never have to keep asking "any news?" And if the line briefly drops, the ticker service automatically reconnects and resumes where it left off. Simple, one-directional, always-on.
Step by Step
Key Concepts
EventSource API
The built-in browser API for SSE. It opens the connection, parses incoming events, dispatches them to your handlers, and manages automatic reconnection — all with a few lines of client code.
text/event-stream Format
The simple line-based wire format: fields like data:, event:, and id:, with a blank line separating events. Easy to produce from any backend by writing to the response stream.
Automatic Reconnection
If the stream drops, EventSource reconnects on its own and sends the Last-Event-ID header, letting the server resume the stream from the last delivered event.
SSE vs WebSockets
SSE is one-way (server to client), text-only, and runs on standard HTTP with built-in reconnection. WebSockets are full-duplex and binary-capable but more complex. Use SSE for server push, WebSockets when the client also sends frequently.
Key Facts
- SSE is simpler than WebSockets for one-directional updates — no protocol upgrade, no extra libraries, and reconnection is built in.
- It runs over plain HTTP, so it passes through most proxies and firewalls that can complicate WebSocket deployments.
- A limitation of SSE over HTTP/1.1 is the per-domain connection cap (about six); HTTP/2 multiplexing removes this constraint.
Real-World Applications
Live notifications and feeds
A dashboard streams alerts or activity updates to the browser via SSE — the server pushes each event as it happens, and the client just listens, with automatic reconnection handling flaky networks.
Progress and AI token streaming
Long-running jobs and LLM responses stream partial results to the UI over SSE, so users see progress or generated text appear incrementally rather than waiting for the whole result.
Frequently Asked Questions
What are Server-Sent Events?
Server-Sent Events (SSE) are a way for a server to push a continuous stream of updates to a browser over a single, long-lived HTTP connection. The browser uses the EventSource API to open the stream and receive events as they arrive. SSE is one-directional (server to client only) and built on standard HTTP, making it simple to implement for real-time feeds and notifications.
What is the difference between SSE and WebSockets?
SSE is one-way — the server streams data to the client — runs over plain HTTP, is text-only, and has automatic reconnection built in. WebSockets are full-duplex (both sides can send), support binary data, and require a protocol upgrade handshake. Use SSE for server-to-client streams like notifications or live feeds; use WebSockets when the client also needs to send messages frequently, such as chat or games.
Does SSE reconnect automatically?
Yes. The EventSource API automatically reconnects if the connection drops. If the server includes an id field with events, the browser sends the Last-Event-ID header on reconnection, allowing the server to resume the stream from the last event the client received, so no updates are missed during a brief disconnection.
When should I use SSE instead of polling or WebSockets?
Use SSE when you need efficient one-way server-to-client updates — notifications, live feeds, progress bars, or streaming AI responses — and want a simple, HTTP-native solution with built-in reconnection. Choose polling only for infrequent updates where simplicity trumps efficiency, and WebSockets when you need low-latency two-way communication.