SSE vs WebSockets — One-Way Stream or Full-Duplex?

The Core Difference

Server-Sent Events is a one-way stream: the server pushes, the client listens. WebSockets are bidirectional. That single axis decides almost everything else.

SSE isn't a new protocol. It's a normal HTTP GET whose response has Content-Type: text/event-stream and simply never closes. The server writes text events over time; the browser's EventSource parses them. No upgrade, no framing protocol.

The SSE Wire Format

It's almost comically simple — line-oriented UTF-8 text, events separated by a blank line:

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

id: 42
event: price
data: {"symbol":"ACME","px":19.20}

id: 43
data: line one
data: line two

: this is a comment / heartbeat to keep the connection warm

retry: 5000

data: — the payload; multiple data: lines are joined with newlines.
id: — an event ID the browser remembers.
event: — a named event type you can listen for.
retry: — how long the browser waits before reconnecting.
: — a comment line, commonly used as a keepalive ping.

Auto-Reconnect & Event IDs — SSE's Superpower

The browser reconnects automatically when the stream drops, and it sends the last ID it saw back in the Last-Event-ID header. The server can resume exactly where it left off. You get at-least-once resumable delivery for free.

sequenceDiagram participant B as Browser (EventSource) participant S as Server B->>S: GET /stream (Accept: text/event-stream) S-->>B: id:42 data:{...} S-->>B: id:43 data:{...} Note over B,S: connection drops B->>S: GET /stream
Last-Event-ID: 43 S-->>B: id:44 data:{...} (resumes)

WebSockets give you none of this. Reconnection, dedup, and "what did I miss?" replay are all your code. That's the hidden tax of reaching for a socket when a stream would do.

The Two Clients, Side by Side

// SSE — the browser handles reconnection + Last-Event-ID for you
const es = new EventSource("/stream");
es.addEventListener("price", (e) => render(JSON.parse(e.data)));
es.onerror = () => {/* browser auto-reconnects; no manual retry needed */};

// WebSocket — you own reconnection, heartbeats, and backoff
let ws;
function connect() {
  ws = new WebSocket("wss://example.com/feed");
  ws.onmessage = (e) => render(JSON.parse(e.data));
  ws.onclose = () => setTimeout(connect, backoff()); // your job
}
connect();

Decision Table

Dimension	SSE	WebSockets
Direction	Server → client only	Bidirectional
Protocol	Plain HTTP (no upgrade)	Upgrade to ws frames
Payload	UTF-8 text only	Text or binary
Auto-reconnect	Built in	Roll your own
Resume (missed events)	Built in (`Last-Event-ID`)	Roll your own
Works with HTTP auth / cookies / proxies	Yes, natively	Partially
Multiplexing	Per-connection limit on HTTP/1.1; fixed by HTTP/2	One connection multiplexes messages

Why SSE Is Underused

Most "we need realtime" requirements are one-directional: live scores, notifications, log tails, LLM token streaming, progress bars, dashboards. For all of these, SSE is less code, survives proxies, resumes cleanly, and rides your existing HTTP auth. Teams reach for WebSockets by reflex and then reinvent reconnection and replay that SSE already ships.

The one real SSE gotcha: on HTTP/1.1, each SSE stream eats one of the browser's ~6 connections per origin. Open several tabs and you starve. Serve it over HTTP/2 (multiplexed streams) and the limit disappears.

Key Takeaways

SSE = one-way server push over an endless HTTP response; WebSockets = full-duplex frames.
SSE gives you auto-reconnect + resumable delivery (Last-Event-ID) for free.
SSE is text-only and rides normal HTTP infra; WebSockets do binary and bidirectional but bypass that infra.
Default to SSE for server→client streams; choose WebSockets when the client also streams.
Run SSE over HTTP/2 to escape the per-origin connection cap.