100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Web Development

WebSockets vs Server-Sent Events

Understanding when to choose bidirectional WebSockets versus the simpler, unidirectional Server-Sent Events (SSE) protocol for server-to-client streaming.

FoundationsIntermediate8 min readJul 10, 2026
Analogies

WebSockets vs Server-Sent Events

Server-Sent Events (SSE) is a standardized, unidirectional server-to-client push mechanism built entirely on plain HTTP, using the text/event-stream MIME type and the browser's EventSource API. Unlike WebSockets, which require a protocol upgrade and support bidirectional messaging, SSE only lets the server push data to the client — but in exchange it gets automatic reconnection handling built into the browser for free.

🏏

Cricket analogy: Like a stadium's PA system broadcasting score updates one-way to every fan (SSE), versus a two-way radio link between the captain and coach where both can speak (WebSockets).

How Server-Sent Events Work

An SSE stream sends plain-text 'data:' lines terminated by a blank line, and each event can carry an optional 'id:' field. The browser's EventSource object automatically reconnects if the connection drops, and it remembers the last event ID it received, sending it back to the server in a Last-Event-ID header so the server can resume the stream from where it left off instead of replaying everything.

🏏

Cricket analogy: Like a scoreboard operator numbering each update ('over 14.3: 4 runs') so if the feed cuts out, it can resume exactly from over 14.3 instead of replaying the whole innings.

javascript
// Server (Express)
app.get('/events', (req, res) => {
  res.set({
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    Connection: 'keep-alive',
  });
  res.flushHeaders();

  let id = 0;
  const timer = setInterval(() => {
    id++;
    res.write(`id: ${id}\n`);
    res.write(`data: ${JSON.stringify({ price: getLatestPrice() })}\n\n`);
  }, 1000);

  req.on('close', () => clearInterval(timer));
});

// Client
const source = new EventSource('/events');
source.onmessage = (event) => {
  const data = JSON.parse(event.data);
  updateTicker(data.price);
};
source.onerror = () => console.log('Reconnecting automatically...');

Directionality: The Key Difference

The defining distinction is direction: WebSockets let the client send data back over the same connection at any time, while SSE only pushes data from server to client — if the client needs to send something, it must issue a separate ordinary HTTP request (like a POST). This makes SSE a great fit for notification feeds, live dashboards, and stock tickers, while chat apps, multiplayer games, and collaborative editors genuinely need bidirectional traffic.

🏏

Cricket analogy: Like a sports app that streams ball-by-ball commentary to your phone (SSE) but requires a separate button tap through a normal form to submit your own prediction (a plain POST), versus a live commentary chat where you can also shout back live (WebSockets).

SSE runs over plain HTTP/1.1 or HTTP/2 and benefits from HTTP/2's multiplexing, avoiding the browser's classic limit of six concurrent connections per origin on HTTP/1.1. Because it's just HTTP, SSE traffic passes through existing proxies, load balancers, and caches far more transparently than a WebSocket's protocol upgrade.

Choosing Between Them

The deciding factor is usually simple: if the client only needs to receive updates, SSE's simplicity, automatic reconnection, and HTTP-friendliness make it the lower-effort choice. If the client also needs to send frequent, low-latency data back — position updates in a game, keystrokes in a collaborative editor — WebSockets' bidirectional channel is worth the added complexity.

🏏

Cricket analogy: Like choosing between a one-way stadium tannoy (good enough for score updates to fans) and a two-way team radio (needed when the captain must actually respond to the coach's instructions mid-over).

SSE only transmits UTF-8 text — there's no built-in way to send binary data like WebSockets' binary frames support. It's also not supported by some older browsers (notably legacy Internet Explorer) without a polyfill, so check your target browser matrix before committing to EventSource.

  • Server-Sent Events (SSE) push data one-way from server to client over a standard HTTP connection using the EventSource API.
  • WebSockets provide full-duplex, bidirectional communication over a dedicated upgraded connection.
  • SSE automatically reconnects and can resume from the last received event ID using the Last-Event-ID header.
  • If a client only needs updates pushed to it, SSE is simpler than standing up a WebSocket server.
  • SSE only supports text (UTF-8) payloads, while WebSockets support both text and binary frames.
  • SSE benefits from ordinary HTTP infrastructure like proxies and caches more easily than WebSockets do.
  • Choose WebSockets when the client must also send frequent, low-latency data back to the server.

Practice what you learned

Was this page helpful?

Topics covered

#WebDevelopment#WebSocketsStudyNotes#WebSocketsVsServerSentEvents#WebSockets#Server#Sent#Events#StudyNotes#SkillVeris#ExamPrep