Side by side
| Dimension | WebSockets | WebRTC |
|---|---|---|
| Primary use | WebSockets: application messages and live updates | WebRTC: interactive media and peer data |
| Connection topology | Client to server | Peer to peer, TURN relay, or media server |
| Transport | TCP-based, commonly secured with TLS | Usually UDP; TCP/TLS relay paths available |
| Delivery behavior | Reliable, ordered within a connection | Media tolerates loss; data channels offer delivery options |
| Media features | Encoding, timing, and adaptation are application work | Built-in media negotiation and congestion handling |
| Connection setup | Connect to a reachable server endpoint | Signaling plus ICE, typically STUN and TURN |
| Scaling infrastructure | Connection gateways, routing, and pub-sub | Signaling, TURN capacity, and often media servers |
| Durability | Requires application storage, acknowledgments, and replay | Also requires application-level persistence and recovery |
The differences that matter
The first decision is where traffic must go. WebSockets naturally route messages through your service, where you can authorize, persist, and fan them out. WebRTC can move data directly between peers, but connectivity and privacy requirements may force a relay. Group calls commonly use a selective forwarding unit, or SFU, rather than a full peer mesh.
WebSockets deliver bytes reliably and in order over TCP. Packet loss can delay later messages while missing data is retransmitted. WebRTC media is designed to keep playback moving despite loss, using congestion control and media-specific recovery. WebRTC data channels can be ordered or unordered, with reliable or partially reliable delivery; those choices are separate from media behavior.
WebRTC adds a connection-establishment subsystem. Your application exchanges session descriptions and ICE candidates through a signaling service, often over WebSockets. STUN helps discover reachable addresses, while TURN relays traffic when a usable direct path is unavailable. Budget relay bandwidth rather than assuming every session will connect directly.
Scaling follows different bottlenecks. WebSocket services need connection placement, cross-server routing, bounded outbound queues, and reconnect handling. WebRTC media services need capacity planning around bitrate, participant count, forwarded streams, and network quality. Neither protocol provides offline delivery or durable history by itself.
Both can encrypt traffic, but the trust boundary differs. WSS protects the client-to-server connection. WebRTC encrypts media and data in transit, but a normal SFU deployment terminates media transport encryption at the SFU; participant-only end-to-end media encryption requires an additional design.
Choose WebSockets when
- You are building chat, notifications, order status, or price updates that must pass through an authoritative server.
- Messages need persistence, access checks, offline delivery, and reconnect replay through your backend.
- You need server-controlled fan-out to many subscribers rather than interactive media sessions.
- Reliable, ordered client-server delivery fits the workload, and you do not need WebRTC's media stack or peer connectivity.
Choose WebRTC when
- You need interactive voice, video, or screen sharing with media-aware congestion control and playback handling.
- You want direct peer-to-peer file transfer when connectivity permits, with TURN fallback when it does not.
- Some updates become useless when late, and an unordered or partially reliable data channel matches that behavior.
- You are building multiparty calls and can operate or use an SFU, signaling service, and TURN infrastructure.
A worked example
A six-person support call with persistent chat
Suppose six participants each publish a 1 Mbps video stream. In a full WebRTC mesh, each participant sends five copies, requiring about 5 Mbps of video upload before protocol overhead. With an SFU, each sends one 1 Mbps stream; forwarding every stream to every other participant gives the SFU roughly 6 Mbps ingress and 30 Mbps egress, before overhead. Actual usage depends on subscriptions, video layers, and adaptation. Use WebRTC for the call and WebSockets for signaling and chat. Persist chat before acknowledging it, then support reconnect replay. Plan TURN capacity for participants who cannot establish a usable direct path to peers or the SFU.
In the interview
- Start with payload and semantics: audio/video, durable chat, or replaceable state updates. State whether late data should be retransmitted, discarded, or replaced.
- Draw signaling separately from the data path. Explain that a WebSocket signaling server does not normally carry the WebRTC media.
- For WebSockets, expect questions about connection routing, slow consumers, reconnect storms, and replay cursors. Transport reliability does not solve those problems.
- For WebRTC, expect questions about ICE failures, TURN fallback, group-call topology, bitrate adaptation, and relay or SFU bandwidth.
- Explain when you would combine them: persist chat and call state in the backend, send signaling over WebSockets, and transport interactive media over WebRTC.
Common mistakes
- Calling WebRTC always peer-to-peer or always UDP, ignoring SFUs and TURN paths over TCP/TLS.
- Assuming WebSockets guarantee message delivery across disconnects, durable storage, or exactly-once processing.
- Claiming WebRTC is universally faster without considering connection setup, routing, packet loss, and delivery requirements.
- Choosing a full peer mesh for large calls without accounting for each participant's upload bandwidth and connection count.
Where it comes up
Interview questions where choosing between WebSockets and WebRTC comes up.
- Design a chat app like WhatsAppUse WebSockets for durable chat delivery and routing, and distinguish that path from optional WebRTC voice or video calls.
- Design BitTorrentWebRTC data channels provide a browser peer-transfer option, but signaling, reachability, TURN costs, and piece verification remain design responsibilities.
- Design Google DocsContrast server-mediated document edits and replay over WebSockets with optional WebRTC collaboration features such as voice or peer presence.
- Design Facebook live commentsServer-authorized comment persistence and hot-stream fan-out favor WebSockets over building a peer mesh or media-oriented delivery path.
Questions people ask
Is WebRTC faster than WebSockets?
There is no universal latency winner. WebRTC media can avoid waiting for reliable retransmission of every packet, which helps interactive audio and video under loss. WebSocket latency depends on the network path, TCP behavior, and server processing; WebRTC also has setup and possible relay costs.
Does WebRTC replace WebSockets?
No. WebRTC handles interactive media and peer data, while WebSockets are a straightforward client-server messaging transport. Many applications use WebSockets to exchange WebRTC signaling messages and maintain server-owned application state.
Should I use WebSockets or WebRTC for a chat app?
Use WebSockets as the default for server-backed text chat, with storage and application-level acknowledgments for durable delivery. Add WebRTC for voice, video, or optional peer-to-peer transfers. WebRTC data channels can carry text, but they do not provide chat history, moderation, or offline delivery.