Server-Sent Events (SSE)

Updated June 6, 2026

Magic Magnets Team

6 min read

HTTP follows a strict request-response cycle. The client asks a question, the server answers. If the server gets new information, it has no way to notify the client without being asked first.

If you're building a live stock ticker, the naive approach is polling: the frontend sends a GET request every 2 seconds asking "any new prices?" This is inefficient. 90% of the time the answer is "No," so you're wasting battery, bandwidth, and server CPU on empty conversations.

Server-Sent Events (SSE) solve this with a simpler, lighter mechanism than WebSockets: a one-way persistent stream from server to client.

How SSE Works

SSE allows a client to open a single HTTP connection to a server. Instead of the server responding immediately and closing the connection (like a normal API call), the server keeps the connection open. Whenever an event happens on the backend, the server pushes a text message down that open pipe.

The client opens the connection using the browser's built-in EventSource API:

const eventSource = new EventSource('/api/stocks/live');

eventSource.onmessage = (event) => {
  console.log("New stock price:", event.data);
};

On the backend, the server responds with Content-Type: text/event-stream. It then streams data chunks separated by double newlines:

data: {"symbol": "AAPL", "price": 150.00}

data: {"symbol": "GOOG", "price": 2800.00}

algobase.dev

Server-Sent Events work over a single, long-lived HTTP connection. The browser opens it once using the EventSource API. The server responds with Content-Type: text/event-stream and keeps the connection open, pushing newline-delimited event chunks whenever data is available. This is strictly one-way — the server pushes, the client listens. Unlike WebSockets, no protocol upgrade is needed. SSE works over plain HTTP/1.1 or HTTP/2, passes through every proxy and corporate firewall without issues, and requires no special server-side infrastructure beyond the ability to hold open connections.

1 / 1

SSE flow — client subscribes once, server pushes events over a single HTTP connection

SSE vs WebSockets

If you want real-time features, you usually choose between SSE and WebSockets.

SSE is the right choice when:

The data flows only one way — server to client. Live news feeds, sports score tickers, and AI text generation are all server-push scenarios. The client only needs to listen.

SSE uses standard HTTP/1.1 or HTTP/2. WebSockets require a protocol upgrade to a custom TCP connection. This means SSE works through corporate firewalls, load balancers, and proxy servers without special configuration.

WebSockets are the right choice when:

The client also needs to send data back to the server frequently. A multiplayer game or a chat application needs bidirectional communication — SSE doesn't support that.

Quiz Time

What is the key difference between SSE and WebSockets?

Built-in Reconnection

One of SSE's most useful properties is automatic reconnection. If a WebSocket drops because a user goes through a tunnel, the developer has to write custom logic to reconnect.

With SSE, the browser's EventSource API reconnects automatically. More importantly, each event can include an id field:

id: 42
data: {"symbol": "AAPL", "price": 150.00}

The browser tracks the last received ID. On reconnect, it sends a Last-Event-ID header so the server knows exactly where the client left off and can resume the stream without gaps.

algobase.dev

One of SSE's most useful features is built-in reconnection. The browser's EventSource API automatically detects a dropped connection and reconnects — no application code needed. More importantly, each event can carry an id field. The browser tracks the last received ID and sends it as the Last-Event-ID header on reconnect. The server can use this to resume the stream exactly where it left off, so the client never misses events during a network blip. This makes SSE a strong choice for streaming AI responses, live dashboards, and notification feeds where delivery reliability matters.

1 / 1

Auto-reconnect with Last-Event-ID — no missed events after a network blip

Quiz Time

How does SSE handle reconnection when a network connection drops?

The AI Streaming Use Case

For years, SSE was underappreciated. Then came large language models.

When you ask ChatGPT a question, it doesn't generate the full 500-word answer at once. It generates one token at a time. If the UI waited for the complete response, you'd stare at a loading spinner for 10 seconds.

OpenAI and nearly every AI tool use Server-Sent Events to stream tokens to the frontend the moment they're generated, creating the familiar "typing" effect. Since the user is just reading (not sending data back during generation), SSE is the right fit here: simpler than WebSockets, works over plain HTTP, and handles reconnection automatically.

When to Use SSE

Use SSE when:

You need server-to-client push and the client doesn't send data back
You want simple infrastructure with no protocol upgrade
You need built-in reconnection and event replay (via Last-Event-ID)
You're streaming AI responses or live notifications

Use WebSockets when:

The client sends data to the server frequently (chat, gaming, collaborative editing)
You need very high message frequency in both directions

Quiz Time

Why do AI tools like ChatGPT use SSE to stream responses instead of returning a single HTTP response?

Summary

Server-Sent Events provide a unidirectional, real-time data stream from server to client over a standard HTTP connection. They solve polling by eliminating empty requests. Compared to WebSockets, SSE is simpler, works over plain HTTP, and features automatic reconnection with event replay. The modern use case that made SSE widely known is streaming AI token generation. For any one-way server-push scenario where the client only listens, SSE is often the better choice than WebSockets.

Webhooks

How helpful was this content?

Comments

0/2000

Saved on this device only