What is the difference between Server-Sent Events and WebSockets?
Quick Answer
Server-Sent Events — a one-way stream from server to client over plain HTTP (EventSource), simple, auto-reconnecting, works through normal proxies. WebSockets — a full-duplex connection, both sides push freely, needed for true two-way real-time (chat, collaborative editing). Use SSE for notifications/live feeds you only push; WebSockets when the client also needs to push continuously.
Server-Sent Events give you a one-directional stream — the server keeps a plain HTTP response open and pushes text events down it, and the browser's EventSource handles reconnects automatically. It's simple and works over ordinary HTTP infrastructure. WebSockets upgrade the connection to a full-duplex socket, so both sides can send whenever they want, which is what you actually need for something like chat or a collaborative editor. If the client only ever receives — a live dashboard, notifications — SSE is simpler and usually sufficient. In ASP.NET Core I mostly don't choose directly; I use SignalR, which negotiates WebSockets and falls back to SSE or long polling depending on what's available.
- SSE is just HTTP, so it plays nicely with existing infra, load balancers, auth cookies; text-only (UTF-8) though you can encode binary as base64.
- WebSockets need an upgrade handshake and their own connection handling; some older proxies/firewalls mishandle them.
- SignalR (ASP.NET) picks the best available transport automatically (WebSockets, falling back to SSE or long polling) so you don't choose manually.
- Both need a plan for connection scaling (backplane/Redis) across multiple server instances.