Is SSE deprecated?
No. Server-sent events are a live part of the WHATWG HTML standard, and the EventSource API they are built on ships in current versions of Chrome, Firefox, Safari, and Edge. No browser vendor has announced a removal, and nothing in the specification is marked obsolete. SSE looks older than WebSockets because it is, not because it is on the way out.
Why people think SSE is obsolete
The API dates from the HTML5 era and has barely changed since, which reads as abandonment if you are used to web platform features that churn. Its documentation sits in the same corner of MDN it has occupied for a decade. Meanwhile WebSockets attracted the frameworks, the conference talks, and the tutorials, so a developer surveying the options today can easily conclude that the quiet one lost.
Three practical annoyances reinforce the impression. The first is that EventSource cannot set request headers, so the usual Authorization: Bearer ... pattern does not work and people fall back to query-string tokens, cookies with withCredentials, or a fetch-based reader. The second is the browser's per-origin connection limit on HTTP/1.1, roughly six, which means a user with several tabs open can exhaust it and see streams that never start. The third is that a reverse proxy or framework configured to buffer responses will hold the stream until the request ends, making a working implementation look broken.
None of those are deprecations. The header limitation is a real gap in the API. The connection limit disappears on HTTP/2 and HTTP/3, where streams multiplex over a single connection. Buffering is a configuration problem, and SSE over HTTP covers what to change.
The evidence that SSE is still current
The clearest signal is what the largest new category of streaming traffic chose. OpenAI's and Anthropic's streaming APIs both deliver tokens as text/event-stream, which is SSE, and so do most other model providers. The web UIs built on top of them stream the same way, which is why ChatGPT uses SSE rather than a WebSocket for its responses. When an entire industry standardizes on a transport in the space of two years, that transport is not being retired.
The format suits the job. Token streaming is one-way, text-based, and needs to survive a dropped connection. SSE gives you all three without a handshake: the client makes an ordinary GET, the server replies with Content-Type: text/event-stream and keeps writing, and the browser reconnects on its own, sending the Last-Event-ID header so the server can resume where it stopped. A WebSocket would need that reconnection logic written by hand.
When to use something else
SSE is one-directional, server to client. If the client needs to send messages on the same connection at arbitrary times, as in a multiplayer game or a collaborative editor, a WebSocket is the correct choice and WebSocket vs SSE walks through the tradeoffs. If you only need occasional updates and can tolerate the delay, ordinary polling is simpler than either.
The other boundary is more often confused. SSE assumes a client holding a connection open, which is fine for a browser and wrong for a backend that has to hear about events from another company's system. That job belongs to webhooks: a short HTTP request sent only when there is something to report, with no connection to keep alive between events. Webhooks vs server-sent events covers the split in full, and what is replacing WebSockets puts both in context alongside the newer transports.
What to check before you commit to SSE
Confirm your infrastructure will not buffer or cut the stream. Load balancers, CDNs, and API gateways often apply an idle timeout of 30 or 60 seconds to responses, which closes an SSE stream that has nothing to send. Sending a comment line (: followed by a newline) as a heartbeat every 15 seconds keeps it open.
Decide how you will authenticate. If a session cookie works, withCredentials is the least effort. If you need a bearer token, either accept it in the query string over TLS and treat it as short-lived, or use a fetch-based stream reader instead of EventSource and give up the automatic reconnection.
Plan for reconnection semantics rather than assuming them. The browser retries on its own, but the server has to attach an id: to each event and honor Last-Event-ID on the next request for a resumed stream to skip what the client already saw. Without that, a reconnect silently loses whatever was published while the connection was down.
If the events you are streaming also need to reach other companies' servers, that is a delivery problem rather than a transport problem: retries, signatures, and per-endpoint logs. Svix provides that layer as a service, so the browser stream and the outbound webhooks can share one event pipeline.
Ready to send webhooks?
Svix handles signing, retries, rate limiting, and delivery observability for the webhooks you send to your users, so your team can stay focused on your product.
Start sending webhooks with Svix or read the build vs. buy analysis