Server-Sent Events (SSE)
A dead-simple way to stream server-to-client updates over plain HTTP — one-directional, auto-reconnecting, and the natural fit for streaming LLM token output.
What are Server-Sent Events?
Server-Sent Events (SSE) is a standard for a server to push a continuous stream of updates to a browser over a single, long-lived HTTP connection. The client opens an EventSource, the server keeps the connection open and writes events as they occur, and the browser receives them in real time. It’s one-directional (server→client only) and built on ordinary HTTP, which makes it dramatically simpler than the alternatives for the common case of “the server needs to tell the client about new things.”
SSE vs WebSockets — pick the simpler tool
The perennial comparison is SSE vs WebSockets, and the honest guidance is use the simpler one that fits. WebSockets give full-duplex (bidirectional) communication over their own protocol — necessary for chat, multiplayer games, collaborative editing, anything where the client streams to the server continuously too. SSE gives server→client only, but in exchange you get: works over plain HTTP (no protocol upgrade, friendlier to proxies and firewalls), automatic reconnection built into the browser’s EventSource (WebSockets make you build reconnection yourself), and far less complexity. For the very common pattern of “stream notifications, live feeds, progress updates, or results to the client,” SSE is often the right, under-used answer — teams reach for WebSockets out of habit when they only ever push one direction.
The 2026 killer app: streaming LLM output
SSE has become the standard transport for streaming LLM responses — the token-by-token “typing” effect you see in AI chat interfaces. It’s a natural fit: the server generates tokens and streams them to the client as they’re produced, one-directionally, over HTTP, with the browser handling reconnection. Most AI provider streaming APIs use SSE for exactly this reason, making it far more relevant now than its low profile would suggest. One real constraint to know: over HTTP/1.1, browsers cap concurrent connections per domain (~6), which can bite apps opening many SSE streams — HTTP/2 multiplexing removes this limit.
What people get wrong
- Reaching for WebSockets by default — if the data only flows server→client, SSE is simpler and gives free reconnection.
- Forgetting the HTTP/1.1 connection cap: ~6 concurrent connections per domain can starve apps with many streams; use HTTP/2.
- Trying to send client→server over SSE — it’s one-directional; client messages go over normal HTTP requests or WebSockets.
Primary source: MDN: Server-Sent Events
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.