Server-Sent Events MIME Type

What does text/event-stream mean?

The text/event-stream MIME type identifies the wire format for server-sent events, usually shortened to SSE. A server keeps an HTTP response open and sends UTF-8 text records as updates become available. Browser code receives those records through the EventSource API.¹²

SSE is one-way. The server sends updates to the client over the open response, while the client uses ordinary HTTP requests when it needs to send something back. That makes SSE a natural fit for notifications, progress updates, live logs, dashboards, and other feeds where the browser mainly listens.²³

The registration recommends no file extension and defines no identifying magic number. It also says the type is intended for dynamic, open-ended streams rather than finite resources.¹ A saved response can still be useful as a debugging capture, but the MIME type describes a streamed HTTP representation, not a conventional document format.

Where did server-sent events come from?

Ian Hickson authored the media-type registration and early EventSource specification work. W3C published Server-Sent Events as a standalone Working Draft in 2009, including the text/event-stream registration template.⁴ The feature later became part of the continuously maintained WHATWG HTML Standard, which remains the format's normative specification.¹²

The design deliberately builds on HTTP and a small line-oriented grammar. That gives browsers a standard way to reconnect and dispatch named events without requiring a bidirectional socket protocol.

How is an SSE message formatted?

An event stream is divided into blocks by blank lines. Within a block, each line has a field name, a colon, and an optional value. The standard gives special meaning to four field names:²

Lines beginning with a colon are comments. They dispatch no event, so servers often use them as periodic keep-alives. Unknown field names are ignored. An event is dispatched only when the parser reaches the blank line at the end of its block.²⁵

This response sends a named progress event followed by an ordinary message:

event: progress
id: job-42-3
data: {"percent":75}

data: Processing complete

Event streams must use UTF-8. Line endings may be CRLF, LF, or CR, and an optional UTF-8 byte order mark is ignored at the start. The charset=utf-8 parameter is allowed for compatibility with older servers, but it cannot select another encoding.¹²

How do you serve and consume text/event-stream?

The server returns an HTTP success response with Content-Type: text/event-stream, then flushes each completed event block instead of waiting for the response to finish. A browser client can connect with a small amount of JavaScript:²⁵

const source = new EventSource("/events")

source.addEventListener("progress", (event) => {
  console.log(JSON.parse(event.data))
})

source.onmessage = (event) => {
  console.log(event.data)
}

EventSource reconnects by default if the connection closes. An id field lets the browser remember a position and report it in the Last-Event-ID request header on a later connection. A retry field adjusts the delay. Calling source.close() stops the connection, and an HTTP 204 No Content response tells a conforming client not to reconnect.²³

Current Chrome, Edge, Firefox, Opera, and Safari releases support EventSource.²³ The browser may still reject a response with an unsupported MIME type, failed CORS checks, invalid HTTP status, or a network error.

Support in Poly

Poly recognizes content that is explicitly labeled text/event-stream. A finite UTF-8 capture opens in the text editor, where its event, data, id, and retry lines remain easy to inspect. Its readable text participates in exact and meaning-based search, and the Poly agent can summarize or reason about the saved capture.

Poly treats the capture as text rather than as a live subscription. It does not connect to an SSE endpoint, wait for future events, replay timing, model reconnection state, or split the stream into individual event objects. Because the media type has no standard extension, a saved file may need its MIME type supplied explicitly; a filename alone does not identify it as text/event-stream.

Is SSE the same as WebSockets or streaming fetch()?

No. All three can deliver incremental data, but they provide different interfaces and message semantics.

SSE can carry JSON inside data: fields, but JSON is payload content rather than the outer framing. Likewise, changing a response's header to application/json removes the SSE media type and does not turn a sequence of event blocks into one valid JSON document.

How do you save, inspect, or convert an event stream?

Command-line HTTP clients are useful for observing an endpoint because they can display bytes as they arrive. Preserve response headers along with the body when diagnosing a problem; the same body can behave differently if its status, MIME type, caching headers, or CORS response changes.

A finite capture can be converted according to its purpose:

• Extract each completed event into newline-delimited JSON for log analysis, while keeping the event type and ID in separate fields.
• Convert selected events to CSV when every payload shares a stable tabular structure.
• Keep the original text when field ordering, comments, blank lines, or malformed input matter to debugging.

Conversion should use an SSE parser rather than splitting on every newline. Multiple data: lines form one payload, comments do not dispatch events, and the final event may remain incomplete if the capture ends without a blank line.²

Security and reliability considerations

An SSE endpoint can expose account activity, operational logs, identifiers, or other private data for as long as the connection remains open. Apply normal HTTP authentication and authorization on every connection, use HTTPS, and configure CORS only for origins that should receive the feed. The media-type registration specifically warns about cross-origin information leakage and resource exhaustion from excessive event traffic or rapid reconnects.¹

Treat every data: value as untrusted. Assigning it to innerHTML, building commands from it, or parsing it without size and depth limits can create the same injection and denial-of-service risks as any other network input. Event IDs also cross a request boundary when the browser sends Last-Event-ID, so servers should validate them rather than treating them as trusted database keys.

Long-lived connections need operational limits. Bound event size, connection duration when appropriate, per-user connection count, buffering, and retry behavior. Send complete records promptly, and use comments as keep-alives only when they are actually needed by the deployment path.