DEV Community

Cover image for What Are Server-Sent Events (SSE)? A Developer's Guide for 2026
Rahul J
Rahul J

Posted on • Originally published at alldevtoolshub.com

What Are Server-Sent Events (SSE)? A Developer's Guide for 2026

#sse #javascript #webdev #beginners

TL;DR

Server-Sent Events (SSE) is a one-way streaming protocol from server → browser built on plain HTTP. The browser opens a connection with new EventSource(url), and the server keeps it open and pushes data: lines whenever it wants. That's it. No WebSocket handshake, no ws://, no upgrade. It auto-reconnects, it works through every proxy that speaks HTTP, and it's been in every browser since 2012.

If you need server → client streaming and you don't need bidirectional messaging, SSE beats WebSockets in almost every way that matters in 2026: less code, simpler infra, auto-reconnect, automatic event IDs for resumability. The only reasons to reach for WebSockets are bidirectional chat-style traffic or binary frames.

Want to see one streaming right now? Open the free SSE tester, paste any SSE endpoint, watch events arrive live.

The 30-Second Mental Model 

[ Browser ]  ──── GET /events ───►  [ Server ]
              ◄── HTTP 200, keep alive
              ◄── data: hello\n\n
              ◄── data: world\n\n
              ◄── data: ...
Enter fullscreen mode Exit fullscreen mode

It's just a long-lived HTTP GET that never closes, with a specific text format on the response body. The MIME type is text/event-stream. Every two newlines flush an event to onmessage. The browser handles framing, parsing, and reconnection — you write eventSource.onmessage = ... and you're done.

The Smallest Possible Example

Server (Node.js — no library needed):

import http from 'node:http';

http.createServer((req, res) => {
  if (req.url !== '/events') {
    res.writeHead(404).end();
    return;
  }

  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive',
  });

  let n = 0;
  const interval = setInterval(() => {
    res.write(`data: tick ${++n}\n\n`);
  }, 1000);

  req.on('close', () => clearInterval(interval));
}).listen(3000);
Enter fullscreen mode Exit fullscreen mode

Client (anywhere — including a <script> tag):

const es = new EventSource('/events');
es.onmessage = (e) => console.log('got:', e.data);
es.onerror = () => console.warn('disconnected, browser will retry');
Enter fullscreen mode Exit fullscreen mode

Run the server, paste the client into the browser console, you have streaming in under 20 lines of code. No build step. No library. No upgrade negotiation. That's the entire pitch.

Why SSE Is Underrated in 2026

I see teams reach for WebSockets reflexively whenever they hear "real-time," then spend a week debugging proxy timeouts, sticky sessions, and ALB upgrade headers. Half the time the use case was server → client only — a feed, a notifications drawer, a build log, a live counter. That's SSE territory.

Here's what you actually get for free with SSE that you'd have to build yourself with WebSockets:

1. Auto-reconnect. When the connection drops, the browser waits ~3 seconds and reconnects. You don't write any code for this. With WebSockets you write the same backoff loop in every project for the rest of your career.

2. Event IDs and resume. If the server sends id: 42\n, the browser sends Last-Event-ID: 42 as a header on the next reconnect. The server can resume from where it left off. This is the feature that makes SSE great for build logs, AI streaming, and audit feeds. With WebSockets, this is a custom protocol you design yourself.

3. Standard HTTP everywhere. SSE is a GET with Accept: text/event-stream. Every proxy, every CDN, every WAF, every reverse proxy understands it (with one caveat — see below). Cookies, Authorization, CORS, compression — all work normally. WebSockets need the upgrade dance and proxies often mishandle it.

4. No framing. Text only, line-delimited. You can curl an SSE endpoint and read the stream in your terminal. Try that with a WebSocket.

curl -N -H "Accept: text/event-stream" https://api.example.com/events
Enter fullscreen mode Exit fullscreen mode

The Anatomy of an SSE Frame

The format is dead simple but trips people up. Each event is one or more lines, terminated by two newlines (a blank line):

event: user-joined
id: 423
retry: 5000
data: {"userId":42,"name":"Ada"}

data: simple message
data: continuation of the same event
Enter fullscreen mode Exit fullscreen mode
  • data: — the payload. Multiple data: lines in the same event get joined with \n.
  • event: — sets the event name. Listen with es.addEventListener('user-joined', ...). If omitted, fires onmessage.
  • id: — what the browser sends back as Last-Event-ID on reconnect.
  • retry: — milliseconds to wait before reconnecting.

The blank line is mandatory. Forgetting the second \n is the #1 SSE bug. Your events buffer in the proxy and the client sees nothing.

When to Use SSE vs WebSockets vs Long Polling

This is the only decision tree you need:

Use SSE when:

  • Traffic is server → client only (notifications, feeds, dashboards, logs, AI token streaming)
  • You want auto-reconnect without writing it
  • You're streaming text (JSON, markdown chunks, log lines)
  • You want to debug with curl

Use WebSockets when:

  • Traffic is bidirectional and high-frequency (chat, collaborative editing, multiplayer games)
  • You need binary frames (audio/video, custom protocols)
  • You need sub-100ms round trips for client → server messages

Use long polling when:

  • You're stuck on infra that breaks both of the above (rare in 2026 but happens behind aggressive corporate proxies)

A full breakdown with code on each side is in the SSE vs WebSockets vs Long Polling deep dive.

The Three Production Gotchas

These are the bugs that hit every team the first time they ship SSE.

1. Proxy buffering kills you

Nginx, by default, buffers responses. Your res.write lands in the buffer; the client sees nothing for minutes. Two fixes, do both:

Server response header:

X-Accel-Buffering: no
Enter fullscreen mode Exit fullscreen mode

Nginx config:

proxy_buffering off;
proxy_cache off;
proxy_read_timeout 24h;
Enter fullscreen mode Exit fullscreen mode

Cloudflare buffers too — you need to put SSE endpoints on a non-cached route, or use a Cloudflare-aware streaming setup.

2. The browser's 6-connection-per-origin limit

Browsers limit you to ~6 open HTTP/1.1 connections per origin. If your app opens an EventSource and the user opens 5 more tabs, the 7th tab hangs because there's no connection slot. Two fixes:

  • Use HTTP/2 or HTTP/3 — connection multiplexing means hundreds of streams over one TCP connection. This is the modern fix.
  • Coordinate across tabs via BroadcastChannel or a SharedWorker — one tab holds the EventSource, broadcasts events to siblings.

3. Heartbeats and idle timeouts

Same trap as WebSockets: load balancers close idle connections. AWS ALB defaults to 50 seconds. Send a comment line every 15-30 seconds:

setInterval(() => res.write(':keepalive\n\n'), 15000);
Enter fullscreen mode Exit fullscreen mode

Lines starting with : are comments per the spec — they keep the connection warm without firing onmessage on the client.

Auth and SSE

EventSource has one annoying limitation: you cannot set custom headers when constructing it. No Authorization: Bearer .... Your options:

1. Cookies (recommended for browser apps) — the browser sends them automatically. Use withCredentials: true and CORS-allow your origin.

const es = new EventSource('/events', { withCredentials: true });
Enter fullscreen mode Exit fullscreen mode

2. Query string token — works but tokens end up in server logs.

3. The fetch + ReadableStream pattern — drops EventSource for fetch, which does accept custom headers. You lose auto-reconnect and have to parse the format yourself, but it's the right call for modern apps with token auth:

const res = await fetch('/events', {
  headers: { Authorization: `Bearer ${token}` },
});
const reader = res.body.getReader();
// ... parse text/event-stream chunks manually
Enter fullscreen mode Exit fullscreen mode

A library like @microsoft/fetch-event-source does this for you and is what most modern AI streaming clients use under the hood.

SSE Is What's Powering AI Streaming

If you've used ChatGPT, Claude, or any AI chat UI in the last two years, you've watched SSE in action. The server streams tokens as they're generated:

data: {"choices":[{"delta":{"content":"Hello"}}]}

data: {"choices":[{"delta":{"content":" world"}}]}

data: [DONE]
Enter fullscreen mode Exit fullscreen mode

Anthropic's, OpenAI's, and Google's streaming APIs all use SSE (or a near-identical custom event-stream format). Knowing SSE means you can debug AI streaming endpoints with the same tools you'd use for any other web protocol.

How to Test an SSE Endpoint

Three ways, in order of when to use each:

1. curl -N — the no-buffer flag. Fastest sanity check.

curl -N -H "Accept: text/event-stream" https://api.example.com/events
Enter fullscreen mode Exit fullscreen mode

2. An in-browser SSE tester — paste the URL, see events live, see headers, see reconnect behavior. Free one here, no install.

3. Browser DevTools → Network → EventStream tab — once your app is open, you can see the parsed event stream live. Chromium-based browsers have a dedicated tab for it.

Common Misconceptions

  • "SSE is dead, WebSockets replaced it." No. WebSockets have grown but SSE never went anywhere — it powers AI streaming, GitHub Actions logs, Vercel deploy logs, Stripe webhooks (well, not technically SSE but the same idea), and most "notifications" features you use daily.
  • "SSE doesn't work with HTTP/2." It works better with HTTP/2 — no 6-connection limit, all streams multiplexed.
  • "SSE is text-only so you can't send binary." True, but base64-encoding small binary payloads in a JSON field is fine, and for real binary streams you should be using WebSockets or just HTTP downloads anyway.
  • "SSE doesn't have ping/pong." Send a comment line (:heartbeat\n\n) every 15s. Done.

FAQ

Is SSE the same as long polling?
No. Long polling = client makes a request, server holds it open until there's data, server responds, client makes another request. SSE = one request stays open forever, server pushes when it has data. Long polling reopens the connection every time. SSE doesn't.

Does SSE work on mobile browsers?
Yes, full support in iOS Safari, Chrome Android, Firefox Mobile. The auto-reconnect handles cellular handoffs fine.

Can I use SSE with React / Vue / Svelte / Solid?
Yes, exactly like you'd use any subscription. Spin up an EventSource in a useEffect (or equivalent), close it in the cleanup, set state on each message.

What's the maximum number of concurrent SSE connections a server can handle?
With Node.js and a sensible setup, tens of thousands per process — connections are mostly idle and consume a few KB of RAM each. Compare to ~32k-65k open file descriptors per process as the real upper bound.

Should I use EventSource or fetch + ReadableStream?
Use EventSource if cookie auth works for you (simpler, auto-reconnect for free). Use fetch if you need Authorization headers or custom request behavior, and pull in a library to handle reconnect.

Originally published on AllDevToolsHub. For 250+ free, privacy-first browser-based developer tools — SSE Tester, WebSocket Tester, JWT Decoder, and more — see alldevtoolshub.com.

Top comments (0)