What is Server-Sent Events?
Also called SSE, EventSource.
Server-Sent Events is a web standard for streaming a one way sequence of text events from a server to a client over a single long lived HTTP response. The response uses the text/event-stream media type and a simple line based format, and browsers consume it through the EventSource interface with automatic reconnection built in.
The wire format is deliberately plain. The server keeps an HTTP response open and writes blocks of lines such as event, data, and id, separated by blank lines. Each block is delivered to the client as one event. Because it is ordinary HTTP over one direction, it works with standard authentication headers, compression, proxies, and observability tooling with no special infrastructure.
Reconnection is part of the specification rather than an application concern. If the stream breaks, a conforming client retries automatically and sends the last received event identifier in a Last-Event-ID header, which lets the server resume from that point. A retry field in the stream lets the server suggest how long the client should wait before reconnecting.
The obvious limitation is direction. Data flows only from server to client, so anything the client wants to send travels as a separate ordinary request. For many use cases this is a feature, since it keeps the streaming path simple and stateless. Where genuinely symmetric messaging is needed, a bidirectional protocol is the better fit.
The format is text only, so binary payloads must be encoded, and the browser EventSource interface historically could not set custom headers, which pushed some implementations to use a fetch based reader instead. Streaming model output is now one of the most common uses, since generated tokens arrive as a natural sequence of small text events.
Key points
- One way server to client stream over plain HTTP
- text/event-stream format with event, data, and id fields
- Automatic reconnection and resume via Last-Event-ID
- Text only; client sends data by separate request
- Common transport for incremental model output
In practice
A completion endpoint responds with content type text/event-stream. As the model generates, the server writes one event per chunk, each a data line holding a small JSON object with the new text. The browser appends each chunk as it arrives, so the answer appears progressively. A final event signals completion, and the server closes the response. No WebSocket infrastructure is involved.