#Server-Sent Events: The Simplest Way to Push from Server to Client

Server-Sent Events is the simplest way to do server push. It is plain HTTP, natively supported by the browser, with no WebSocket and no library required. That is why it is hot again in the age of AI streaming.

#What it is

Server-Sent Events, or SSE, is part of the HTML5 specification. It lets a server push updates to a client over a single long-lived HTTP connection. The server responds with a Content-Type: text/event-stream and sends events as text. The client uses the browser-native EventSource API to receive them. There is nothing outside of HTTP involved.

Think of SSE like a radio. The server broadcasts continuously, and the client opens a channel once and listens. There is no need to call back and ask for updates the way polling does. It is one-way, server-to-client, and continuous. The event format is minimal: each event is a line starting with data: followed by the text content, and events are separated by a blank line. You can add an id field for resumption and an event field for categorization, but that is the entire protocol.

#Why it matters

• It is pure HTTP, so browsers support it natively through EventSource with no library needed.
• Reconnection is automatic and free. The browser reconnects on its own and sends a Last-Event-ID header so the server can resume from the last event the client received.
• It is dramatically simpler than WebSocket for one-way push, with no handshake, heartbeat, or reconnect logic to write.
• It is ideal for AI token streaming and live feeds, which is why OpenAI's streaming API uses SSE.
• It reuses existing HTTP infrastructure, including proxies, caches, and authentication.

#How it works

On the client side, three lines of code are enough. Create an EventSource pointing at your stream endpoint, attach an onmessage handler, and you are receiving events. The browser handles reconnection automatically. When the connection drops, EventSource reconnects on its own and sends the Last-Event-ID header, so the server knows which event to resume from. No events are lost.

On the server side, you set the response content type to text/event-stream, keep the connection open, and write events as they happen. Because it is plain HTTP, everything you already have, load balancers, caches, auth middleware, works without modification. The simplicity is the point. For AI streaming, each token the model generates is sent as a separate event, so the client renders text as it arrives instead of waiting for the full response.

#Caveats

SSE is strictly one-way. The client cannot send messages back over the same connection, so if you need bidirectional communication, use WebSocket. SSE is text-only, with no binary support, so images and video must be base64-encoded or sent over a separate channel. Browsers limit SSE to six concurrent connections per domain under HTTP/1.1, though HTTP/2 removes that limit. SSE is not the right choice for chat applications where both sides need to send messages freely.

#Who it's for

SSE is for developers building one-way server push features: AI token streaming, live stock feeds, notifications, progress updates, and log streaming. If you only need the server to push continuous updates and the client does not need to send data back, SSE is lighter and simpler than WebSocket.

SSE is the simplest option for one-way server push. Use it for AI streaming and live feeds, and reach for WebSocket only when you actually need two directions.

Source: https://html.spec.whatwg.org/multipage/server-sent-events.html