Server-Sent Events
Server-Sent Events is a simple, HTTP-based protocol for unidirectional server-to-client streaming that provides automatic reconnection and event ID tracking out of the box.
SSE lets a server push updates to the browser over a standard HTTP connection. The client opens a connection with EventSource, and the server sends a stream of text events. Unlike WebSocket, SSE is server-to-client only, but it has major advantages: it works over standard HTTP (no upgrade needed), has automatic reconnection built in, supports event IDs for resuming after disconnects, and works seamlessly with proxies, CDNs, and load balancers. It's simpler than WebSocket when you only need server push — think live feeds, notifications, and LLM token streaming.
Strengths
- Built-in automatic reconnection with Last-Event-ID resumption — zero client-side retry code needed
- Standard HTTP protocol — works seamlessly with proxies, CDNs, load balancers, and firewalls
- Extremely simple protocol format — plain text with minimal parsing overhead
- Native browser support via EventSource API with no libraries or polyfills needed
- Perfect fit for AI/LLM token streaming, now the dominant use case for the protocol
- Named events allow multiplexing multiple event types over a single connection
Weaknesses
- Unidirectional only — server-to-client; clients must use separate HTTP requests to send data
- Text-based format only — no native binary data support (must Base64-encode)
- HTTP/1.1 limits browsers to ~6 concurrent SSE connections per domain (resolved by HTTP/2)
- Higher per-message overhead (~50 bytes) compared to WebSocket's 2-14 byte framing
- No built-in backpressure mechanism — fast servers can overwhelm slow clients
- Cannot send custom headers during automatic reconnection — authentication requires cookies or query params
Technical Profile
Latency Profile
SSE delivers events with HTTP-level latency — typically 10-50ms over the internet. After the initial HTTP connection, subsequent events are pushed immediately without per-event handshake overhead. Latency is slightly higher than WebSocket due to HTTP framing and text encoding, but the difference is negligible for most applications. Keep-alive heartbeats (typically every 15-30 seconds) maintain the connection through NAT gateways and proxies.
Payload Format
Text/JSON
Browser Support
Yes
Streaming Support
Server-sent only
Schema Enforcement
None
Ideal Use Cases
- AI/LLM response streaming (token-by-token delivery of generated text)
- Real-time notifications and activity feeds (social media, collaboration tools)
- Live dashboards and monitoring with server-pushed metric updates
- CI/CD build log streaming to browser-based developer tools
- Live event coverage (sports scores, election results, stock tickers)
Real-World Examples
ChatGPT and the OpenAI API use SSE to stream generated tokens in real-time, delivering responses word-by-word as the model produces them
Claude API uses SSE for streaming message responses, allowing clients to display partial responses as tokens are generated
Uses SSE for live updates on pull request checks, deployment status, and Actions workflow logs in the browser UI
Streams deployment build logs to the browser dashboard using SSE, showing real-time progress as builds execute
Uses SSE for real-time notification delivery to the web client, including connection requests, messages, and post reactions
Likely Follow-Up Questions
- When would you choose SSE over WebSocket, and when would WebSocket be the better choice?
- How does SSE's automatic reconnection with Last-Event-ID work, and how would you implement the server side to support resumption?
- How does the HTTP/1.1 six-connection-per-domain limit affect SSE, and how does HTTP/2 solve this?
- How would you implement authentication for an SSE endpoint, given that EventSource doesn't support custom headers?
- How would you scale an SSE-based notification system to millions of concurrent users across multiple servers?
Related Concepts
Source: editorial — Synthesized from the W3C Server-Sent Events specification, MDN documentation, and production usage patterns from OpenAI, Anthropic, GitHub, and Vercel engineering teams.