DEV Community: Rahul J

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

Rahul J — Sun, 24 May 2026 11:04:24 +0000

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: ...

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);

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');

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

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

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

Nginx config:

proxy_buffering off;
proxy_cache off;
proxy_read_timeout 24h;

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);

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 });

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

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]

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

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.

How to Test WebSocket Connections Online in 2026 — A Debugging Field Guide

Rahul J — Sun, 24 May 2026 11:04:13 +0000

TL;DR

You don't need Postman or a paid tool to test WebSockets. In 2026, the four tools that cover 99% of real debugging are: the browser DevTools Network tab, an in-browser tester, wscat for CI, and a 20-line Node.js client. Pick by what you're verifying — handshake, message flow, close code, or auth header — not by habit.

If you want to skip the survey and just paste a wss:// URL into something that works, open a free browser-based WebSocket tester — no install, no signup, full handshake + close-code output.

The Bug That Inspired This Post

A real one. A team I was helping had a chat app dropping connections in production every 47 seconds. Local: fine. Staging: fine. Production: dead at 47s, every time.

Three engineers had spent two days on it. They were testing in Postman because that's the tool they knew. Postman happily reported "connected" and "disconnected" but gave them no useful detail about why the disconnect happened.

The fix took 90 seconds in a different tool: open an in-browser WebSocket tester, paste the production URL, watch the close frame come in as code 1006 (abnormal closure), then trace it back to the AWS ALB's idle timeout being 50 seconds with no app-level heartbeat. Send a ping every 30s, problem gone.

This is the lesson: the tool you reach for first determines what bug you can see. Most WebSocket bugs aren't "it didn't connect." They're "it connected, did some stuff, and died in an interesting way." If your tool only shows green/red, you're flying blind.

The Four Things You Actually Need to Verify

Before picking a tool, pin down what you're actually testing:

The handshake — does the server return HTTP 101 Switching Protocols? Does it echo your Sec-WebSocket-Protocol?
Bidirectional messaging — can text frames go both ways? Binary frames without corruption?
Close behavior — when the connection drops, what close code comes back? 1000 (normal)? 1006 (abnormal)? 4xxx (your app's custom code)?
Auth + headers — do cookies make it through? Authorization? Custom Sec-WebSocket-Protocol for token-as-subprotocol auth?

If your testing tool can't show you all four, you're going to miss bugs.

Tool 1 — Browser DevTools Network Tab (Always Available)

Best for: verifying your own frontend's existing connection, watching live messages during normal usage.

Open DevTools → Network → filter "WS" → click the connection. You get the upgrade headers, response, and a "Messages" sub-tab that streams frames in real time.

The limit: you cannot initiate a new connection here. You can only watch one your app already opened. So this is a passive tool — great for "what is my app actually sending?", useless for "is this server endpoint up?"

Tool 2 — In-Browser WebSocket Tester (Fastest for New Endpoints)

Best for: smoke-testing a new endpoint, ad-hoc message replay, sharing a repro with a teammate.

Paste a wss:// URL, click connect, type messages, watch the close code on disconnect. The whole point is zero setup — no npm install, no auth, no account.

I'm biased here: I built one because I was tired of every alternative either requiring a download or a login. The one on AllDevToolsHub runs entirely in your browser, shows the named close code (1006 → "Abnormal Closure"), and supports auth via subprotocols. But there are several — pick one you trust, since you'll paste auth tokens into it.

One gotcha: in-browser testers run from a different origin than your app. If your server checks Origin headers (it probably should), it may refuse the test connection. That refusal is itself useful debugging info — it means your origin check works.

Tool 3 — `wscat` (For Scripts and CI)

Best for: smoke tests in CI, reproducible test cases in bug reports.

npm install -g wscat
wscat -c wss://api.example.com/ws -H "Authorization: Bearer $TOKEN"

Now you have a terminal that sends text frames and prints incoming ones. Pipe stuff in, capture stuff out, exit code reflects success.

In CI:

echo '{"type":"ping"}' | timeout 5 wscat -c wss://api.example.com/ws -x '{"type":"ping"}' -w 2

wscat does not speak binary frames well and doesn't expose close codes prominently. For protocol-level debugging, use a real client. For "is the endpoint up?", it's perfect.

Tool 4 — A 20-Line Node.js Client (For Deep Debugging)

Best for: anything the above tools can't show you. Binary frames. Custom backpressure. Reconnect logic. Long-running soak tests.

import WebSocket from 'ws';

const ws = new WebSocket('wss://api.example.com/ws', {
  headers: { Authorization: `Bearer ${process.env.TOKEN}` },
});

ws.on('open', () => {
  console.log('[open]', new Date().toISOString());
  ws.send(JSON.stringify({ type: 'subscribe', channel: 'orders' }));
});

ws.on('message', (data, isBinary) => {
  console.log('[msg]', isBinary ? `<binary ${data.length}b>` : data.toString());
});

ws.on('close', (code, reason) => {
  console.log('[close]', code, reason?.toString() || '(no reason)');
});

ws.on('error', (err) => console.error('[error]', err.message));

// Heartbeat — this is what the 47-second-bug team was missing
setInterval(() => ws.ping(), 30000);

That's the whole thing. Drop into a file, node test.js, watch console. If you can't fit your test into 20 lines of Node, you're not testing — you're building.

The Production Gotchas You Won't Catch in Local Dev

These are the ones that bit me, in approximate order of how often I see them:

1. ALB / proxy idle timeouts. AWS Application Load Balancers default to a 50-second idle timeout. No heartbeat? Connection dies at 47-50s, every time. Cloudflare's default is 100s. Nginx's proxy_read_timeout is 60s. Always send an app-level ping at half the proxy's timeout.

2. Sticky sessions and reconnect. If you reconnect after a deploy, you may land on a different server with no memory of your session. Tools that don't expose the reconnect handshake make this invisible.

3. Origin header on wss://. Browsers send it, wscat and Node don't unless you explicitly add it. If you test from Node and it works, then test from a browser and it fails, check origin policy first.

4. Close codes ≠ status codes. 1006 is the code you'll see most in production, and it means "the close frame never arrived." Could be network, could be a crash, could be a proxy killing the connection. Don't treat it as an error type — treat it as "tell me more."

5. Sec-WebSocket-Protocol for token auth. When you can't set a cookie or Authorization header (browser WebSocket constructor doesn't accept custom headers), some apps pass tokens as a subprotocol. Your tester needs to support subprotocol negotiation, or you'll be debugging an auth bug as a "handshake failure."

Common Mistakes I See in WebSocket Tests

These get bookmarked and shared more than anything else in this post, so here they are upfront:

Testing only the happy path. A WebSocket test that doesn't include a forced disconnect is incomplete. Pull the network cable. Kill the process. Send a malformed frame. See what your client does.
Confusing onerror with the close code. Browsers fire a generic error event and then fire close with the actual reason. If you only log the error, you've thrown away the diagnostic.
Assuming ping/pong is automatic. It isn't in browsers. The ws Node library does it. socket.io does it. Raw browser WebSocket does not.
Forgetting that 4xxx close codes are your responsibility. Codes 4000-4999 are reserved for application use. If you're not defining any, you're throwing away information at exactly the point things go wrong.
Testing against localhost and shipping to production. Local doesn't have proxies, idle timeouts, or origin enforcement. The whole point of a remote tester is to catch what local hides.

Quick Reference: When to Use Which Tool

Scenario	Best Tool	Why
"Is this endpoint alive?"	wscat or in-browser tester	Fastest path to a yes/no
"What is my frontend sending?"	DevTools Network tab	Already there, passive observation
"Why does it die at 47 seconds?"	In-browser tester (for close code) → Node script (for ping cadence)	Need close-code visibility, then heartbeat customization
"Does auth work?"	wscat with `-H "Authorization: ..."` or Node script	Browser WebSocket can't set arbitrary headers
"Soak test for 6 hours"	Node script in a loop	Only thing flexible enough
"Repro in a bug report"	wscat command + paste output	Reproducible, copy-pasteable

Try It Online

The fastest way to test a WebSocket endpoint right now: paste the URL into AllDevToolsHub's WebSocket Tester. It runs entirely in your browser, shows the handshake + every frame + the named close code, and you don't sign up for anything. If you want the deeper version of this guide — RFC 6455 details, full close-code reference, end-to-end auth examples — read the full guide on AllDevToolsHub.

FAQ

What's the difference between wss:// and ws://?
wss:// is WebSocket over TLS (the WebSocket equivalent of HTTPS). Always use it in production. Browsers refuse ws:// from HTTPS pages anyway.

Why does my connection die at exactly 50 or 60 seconds?
Proxy idle timeout. AWS ALB defaults to 50s, Nginx to 60s. Add a ping every 30s from either client or server.

Can I test WebSockets from curl?
Only the handshake (curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" ...). Once the connection upgrades, curl can't read the framed protocol. Use wscat instead.

Do I need Postman for WebSocket testing?
No. Postman's WebSocket support is fine but the free browser-based tools cover the same ground without the install. Postman is worth it for REST + WebSocket + GraphQL in one place; for WebSockets alone it's overkill.

What's the most important close code to know?
1006 — "abnormal closure." It means the close frame never made it across, which means something killed the connection unexpectedly. You will see this constantly. Full close-code reference is here.

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

JSON Security 101: Handling Sensitive Data Locally

Rahul J — Sat, 11 Apr 2026 07:21:08 +0000

JSON Security 101: Handling Sensitive Data Locally

JSON is the language of the web. But it’s also the carrier of some of our most sensitive data: API keys, user PII, and internal configurations.

When you need to format a nested JSON object to make it readable, where do you turn?

The "Cloud" trap

Most online JSON formatters are actually proxying your data through a server. Even if they claim not to store it, the data is still transmitted over the wire to a backend they control. For a developer handling production data, this is a massive compliance risk.

Enter Local-First JSON Tools

At AllDevToolsHub, we believe formatting JSON shouldn't require an internet connection or a leap of faith.

Our JSON Formatter and JSON Anonymizer run entirely in your browser window.

Key Tools for JSON Security:

JSON Formatter: Prettify and minify data with custom indentation, all offline.
JSON Anonymizer: Automatically replace sensitive values with mock data before sharing logs with colleagues.
JSON Schema Validator: Validate your structure against standard schemas without leaking the schema itself.

How to Stay Secure

Verify Client-Side Execution: Open your browser's "Network" tab. If you click 'Format' and no request goes out, you're safe.
Anonymize First: Always mask user emails and phone numbers before using any external tool.
Bookmark Trustworthy Hubs: Use AllDevToolsHub for all your formatting needs.

Keep your data where it belongs: on your machine.

Stop Sending Your JWTs to Random Online Decoders

Rahul J — Sat, 11 Apr 2026 07:06:22 +0000

Stop Sending Your JWTs to Random Online Decoders

As developers, we've all been there. You're debugging an authentication issue, you've got a JWT string, and you need to see what's inside it. You quickly search for "JWT Decoder" and click the first result.

Stop right there.

Every time you paste a JWT into a third-party website, you are potentially exposing:

User Emails & IDs: Stored in the payload.
Permissions/Scopes: Revealing how your auth system is structured.
Internal Server Data: Anything else you've tucked into the claims.

If that third-party site logs your input (which many do for "analytics"), someone else now has a valid access token for your system.

The Local-First Solution

This is why we built AllDevToolsHub. Our JWT Decoder and JWT Tool run 100% in your browser.

How it works:

Zero Server Interaction: Your token never leaves your machine. The decoding logic is written in pure JavaScript that executes locally.
Privacy by Design: We don't log your inputs. We don't even have a database to store them in.
Speed: No network round-trips mean instant results.

Best Practices for Token Debugging

Check the Source: Only use tools that explicitly state they are client-side only.
Audit Your Claims: Regularly review what data you're putting into your JWTs. Keep it minimal.
Use Local Tools: Bookmark the AllDevToolsHub JWT Decoder for a secure, fast experience.

Stop gambling with your user data. Stay local. Stay secure.

DEV Community: Rahul J

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

TL;DR

The 30-Second Mental Model

The Smallest Possible Example

Why SSE Is Underrated in 2026

The Anatomy of an SSE Frame

When to Use SSE vs WebSockets vs Long Polling

The Three Production Gotchas

1. Proxy buffering kills you

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

3. Heartbeats and idle timeouts

Auth and SSE

SSE Is What's Powering AI Streaming

How to Test an SSE Endpoint

Common Misconceptions

FAQ

How to Test WebSocket Connections Online in 2026 — A Debugging Field Guide

TL;DR

The Bug That Inspired This Post

The Four Things You Actually Need to Verify

Tool 1 — Browser DevTools Network Tab (Always Available)

Tool 2 — In-Browser WebSocket Tester (Fastest for New Endpoints)

Tool 3 — wscat (For Scripts and CI)

Tool 4 — A 20-Line Node.js Client (For Deep Debugging)

The Production Gotchas You Won't Catch in Local Dev

Common Mistakes I See in WebSocket Tests

Quick Reference: When to Use Which Tool

Try It Online

FAQ

JSON Security 101: Handling Sensitive Data Locally

JSON Security 101: Handling Sensitive Data Locally

The "Cloud" trap

Enter Local-First JSON Tools

Key Tools for JSON Security:

How to Stay Secure

Stop Sending Your JWTs to Random Online Decoders

Stop Sending Your JWTs to Random Online Decoders

The Local-First Solution

How it works:

Best Practices for Token Debugging

Tool 3 — `wscat` (For Scripts and CI)