Short answer: if the data is going between your users, use WebRTC. If it's going between a user and your server, use a WebSocket.
That gets you most of the way. The refinement is that "between your users" isn't only about geography, it's about ownership: once your server has to see, authorise, order, or keep the data, it belongs on a WebSocket even when the recipient is another person.
Most applications have both kinds of traffic. So "versus" is usually the wrong frame.
Find your app
| What you're building | Use | Why |
|---|---|---|
| Video or voice call between users | WebRTC | Built for live media: adaptive bitrate, jitter buffers, echo cancellation |
| Game state, shared cursors, live drawing | WebRTC data channel | Can take a direct path, and can drop stale updates instead of queueing them |
| Direct file transfer between users | WebRTC data channel | Skips your servers entirely when ICE finds a direct route |
| Chat you store, search, or moderate | WebSocket | Your server has to see and keep it |
| Notifications, dashboards, price feeds | WebSocket | The data starts on your server |
| Server-authoritative multiplayer | WebSocket | Clients aren't peers. Your server is the referee |
| AI voice agent in the browser | WebRTC | One end is a cloud model. More below |
| Connection setup for a WebRTC app | WebSocket or HTTP | WebRTC needs signalling but doesn't dictate how you carry it |
TL;DR: A WebSocket is a pipe to your server. Simple, reliable, and the right answer whenever the server owns the state. WebRTC is a whole real-time stack that prefers a direct path between endpoints and falls back to a TURN relay when it can't get one. You pay for that in signalling, ICE negotiation and relay capacity, and you get back real media handling, configurable delivery, and traffic that mostly bypasses your infrastructure. Plan on roughly one connection in five needing the relay.
Are they even alternatives?
Not really. They do different jobs.
A WebSocket connects a client to your server. One long-lived TCP connection, either side can send whenever it likes, and every byte moves through infrastructure you run or pay for.
WebRTC connects two endpoints to each other. It negotiates a network path, encrypts everything, adapts live media as conditions change, and sends the traffic directly when ICE can find a workable route between the two. When it can't, a TURN server relays it.
So don't start with the protocols. Start with where the data needs to go, then ask whether your server has to be involved in it.
That's why real applications usually ship both. A video call app sends media over WebRTC and handles presence, permissions and room state over a WebSocket. A collaborative editor might throw cursor positions across a data channel while sending the actual document operations to the server, because those need to be ordered and stored.
Four questions that settle it
- Does your server need to inspect, authorise, persist, moderate, or reconcile this data? If yes, WebSocket. This one usually decides it on its own.
- Would the extra hop through your server actually hurt? Latency and bandwidth both count here.
- Can an update be thrown away? Data channels can be unordered and unreliable on purpose. WebSocket is ordered, always.
- How many endpoints? Two is easy. Past a handful, mesh stops working and you need a different topology.
The mistake worth avoiding
Reaching for a WebSocket by default, and using it for data that was never going to your server in the first place.
It's an easy habit. WebSockets are simpler to think about, every tutorial starts with one, and the thing works immediately. So cursor positions and transient player state get routed up to a datacentre and back down, and nobody notices because it works fine with four people in the room.
The reverse mistake is real too, and it's the more expensive one to fix. Pushing server-owned state onto a peer-to-peer channel because the recipient happens to be another user. Moderated chat, authoritative game state, anything that needs conflict resolution — those want a server in the path even though a human is on the other end. Destination narrows the choice. Ownership finishes it.
What a data channel actually gets you
Most people know WebRTC does video. Fewer know it will carry any data you like, and that half is often the more useful one.
A data channel moves bytes between endpoints. When ICE finds a direct route, that payload never reaches your servers and never pays for the trip through a datacentre. When it can't, the same channel runs over TURN and that traffic does cost you relay bandwidth.
You also get a control the WebSocket API doesn't offer at all. A channel can be unreliable and unordered on purpose:
const channel = pc.createDataChannel('game-state', {
ordered: false, // deliver out of order rather than waiting
maxRetransmits: 0 // don't retry — the next update supersedes this one
});
Which is exactly what you want for a cursor. An update from 200 ms ago is worthless the moment a newer one lands, so retransmitting it is worse than dropping it.
Over a WebSocket you don't get the choice. TCP delivers in order, so one lost packet holds up everything behind it while the network sorts itself out, and your server forwards every byte in both directions.
For files, keep the channel reliable and ordered. And budget for chunking and backpressure while you're there. A data channel changes the route your bytes take, not your need for flow control.
What am I signing up for if I choose WebRTC?
More than a WebSocket asks of you. Here's the whole list.
It can't start on its own
Two peers can't exchange anything until they've swapped session descriptions (SDP) and network candidates (ICE). That exchange has to travel over something that already works.
That something is signalling, and WebRTC deliberately doesn't tell you how to build it. WebSocket is the common choice because it's bidirectional and you probably want one anyway for presence. HTTP works. So does SIP. The requirement is a signalling service, not specifically a WebSocket service.
Signalling only sets the connection up. Once ICE picks a candidate pair, media and data-channel traffic follow that path and leave signalling behind.
We went through the handshake properly in WebRTC Signaling Server: How It Works, and MDN's guide covers why the transport is left to you.
Some connections can't go direct
A share of your users won't get a direct path at all, and their traffic has to be relayed through TURN. Two production datasets put that share near one in five:
| Dataset | Relay rate | Source |
|---|---|---|
| 10 million peer-to-peer Chrome calls | 17.7% | appear.in rtcstats, Philipp Hancke, Aug 2017 |
| Conferences across 100+ customers, 13 months | 22% | callstats.io, Lumiaho & Singh on webrtcHacks, Apr 2016 |
Both are old, and neither is your number. Relay rate moves with your users' geography, their devices, how many of them sit behind corporate firewalls or mobile carriers, and where you put your ICE servers. Treat one in five as the order of magnitude to plan around, then measure your own selected candidate types once you're in production.
The mechanism behind it is worth understanding, because it explains why the number swings.
Most home routers keep a public mapping stable long enough for two peers to find each other through STUN and connect. Some networks don't. Symmetric NAT — endpoint-dependent mapping, more precisely — hands out a different public mapping for every destination, so the address a peer learns about itself through STUN isn't an address anyone else can reach it on. Carrier-grade NAT does similar things. Firewalls that block UDP outright remove the remaining candidates.
When ICE runs out of workable pairs, TURN is what's left.
That's why an enterprise or mobile-heavy audience relays more than a consumer one. There's a detail in the appear.in numbers that shows it: 78% of the relayed calls in that sample went over TURN/TCP rather than UDP. Restrictive networks were doing most of the work.
In practice: stand TURN up on day one and test against a genuinely hostile network before you ship. Without it, the users who have no direct path get a connection that negotiates, reports itself as connected, and carries nothing.
Is WebRTC actually faster?
For traffic between two users, yes, and for two reasons that stack.
One hop instead of two. A WebSocket message from A to B goes up to your server and back down. A direct data channel goes straight across. Sydney to Sydney via Virginia is a real penalty, and plenty of apps are paying it without realising.
Delivery built for real-time. WebRTC prefers UDP, and its media stack is designed to keep playing through jitter and loss rather than stop and wait. TCP does the opposite by design: it holds later data until the missing packet arrives. That's correct for a file and wrong for an audio frame that's already stale.
The honest caveat: a relayed WebRTC connection gives some of the hop advantage back, since the traffic is going through a server after all. It keeps the media-handling advantage regardless.
For client-to-server traffic, WebRTC doesn't shorten anything. The data has to reach your server either way.
| WebSocket | WebRTC | |
|---|---|---|
| Path | Always via your server | Direct when possible, relayed when not |
| Transport | TCP | Usually UDP; TURN over TCP/TLS on restrictive networks |
| Ordering | Reliable and ordered, always | Media is real-time optimised; data channels are configurable |
| Media features | None. You build them | Adaptive bitrate, jitter buffer, echo cancellation |
| Your bandwidth | Every byte | Only the relayed connections |
| Setup | Open the connection | Signalling plus ICE negotiation |
| Browser support | Broad | Broad |
Can I start with a WebSocket and switch later?
Yes, and plenty of teams should. A WebSocket relay is fast to stand up and it lets you find out whether anyone wants the product before you take on ICE state machines.
Just be clear-eyed that the switch isn't a transport swap. You'll be adding signalling, connection-state handling, ICE negotiation and relay capacity, all on top of a system that already has users on it.
Two things make that migration much cheaper, and both cost almost nothing today:
Keep payloads transport-agnostic. If your app code calls send(message) instead of reaching into a socket, replacing what sits underneath is contained.
Sort your traffic by owner, not by type. Which messages does your server actually need to see? Everything else is a candidate for a data channel later. Doing that classification early is most of the work.
If you already know live media or heavy peer-to-peer data is coming, start on WebRTC. Same work either way, and it's smaller before you have production traffic sitting on it.
What about AI voice agents?
Voice agents put this decision in front of a lot of teams at once, because the major platforms support both transports and let you choose.
The OpenAI Realtime API offers WebRTC and WebSocket connection methods, and OpenAI's own guidance points browser and mobile clients at WebRTC for more consistent performance. Pipecat ships WebRTC transports alongside WebSocket ones.
There's a structural difference here that changes the maths. A voice agent usually isn't user-to-user. The browser is talking to a model in the cloud, so one end is a server.
Which means the connectivity question shifts. If you terminate WebRTC on infrastructure you run, test the corporate and mobile networks properly and make sure there's a TURN path for them. If you're using a managed Realtime API, find out what the provider handles before assuming it behaves like a browser-to-browser call. We looked at the self-hosted case in TURN for AI Voice Agents.
For a browser-side voice experience, start with WebRTC. Keep WebSocket for server-to-server integrations and control events, where ordered delivery matters more than live-media behaviour.
What you need to actually ship it
If you're running WebRTC yourself, two services come with it. Both are easy to skip while you're prototyping, because on a friendly network everything connects and nothing goes wrong.
A signalling service. Usually a WebSocket service carrying SDP and ICE candidates, plus rooms and presence. Quick to prototype, considerably harder once you need authentication, reconnection, ordering and scale. We built one from scratch in WebSocket Server: How to Build One.
A TURN relay. For the sessions where ICE can't find a direct path, which is the one in five above.
Both, from Metered
Open Relay gives you 20 GB of free TURN every month. That's enough to build on, deliberately test the fallback path, and run a small product without a bill.
Metered TURN is the production service. 31+ regions and 100+ edge PoPs, so the relay sits near your users rather than near your datacentre. It listens on ports 80 and 443 with TURNS over TLS, which is the part that gets you through the corporate firewalls generating most of your relay traffic to begin with. Credentials come from a REST API, so each session gets its own short-lived credential and no permanent secret ever reaches the browser.
Metered Realtime handles signalling: SDP and ICE exchange, presence, pub/sub. It's free, with 100 concurrent connections and 100,000 messages a month. Open Relay credentials are injected when a client connects, so signalling and TURN show up already wired to each other instead of as an integration project.
The client is @metered-ca/realtime — MIT licensed and open source, with Python and Flutter SDKs alongside the JavaScript one. Sending data to a room or to one peer is the whole of it:
import { MeteredPeer } from '@metered-ca/realtime';
const peer = new MeteredPeer({ apiKey: PUBLISHABLE_KEY });
await peer.join('room-id');
peer.on('data', ({ senderPeerId, data }) => {
render(senderPeerId, data);
});
await peer.send({ type: 'cursor', x: 420, y: 96 });
// or, to one peer:
await peer.sendTo(otherPeerId, { type: 'cursor', x: 420, y: 96 });
No signalling server to write, no ICE configuration to assemble, and the relay is already there for the users who need it.
Frequently asked questions
Should I use WebSocket or WebRTC?
WebRTC when the data goes between your users and benefits from a direct, real-time path. WebSocket when your server originates the data, or has to authorise, order, store or moderate it. Most apps have both kinds and use both.
Is WebRTC faster than WebSocket?
Between two users, usually. A direct path is one hop instead of two, and UDP doesn't stall live media waiting for a retransmission. A relayed connection gives back some of the hop advantage but keeps the media handling. For client-to-server traffic there's no gain, because the data has to reach your server anyway.
Can I use WebRTC without a server?
No. You need a signalling mechanism to exchange connection details, and TURN for the networks where ICE can't find a direct pair. "Peer-to-peer" describes where the media ends up flowing, not an absence of infrastructure.
Do I still need WebSockets if I use WebRTC?
Usually, though not because WebRTC demands it. Signalling transport is your choice; WebSocket is popular because it's bidirectional and doubles as your presence channel. HTTP or SIP work too.
When should I use a data channel instead of a WebSocket?
For traffic between users that your server doesn't need to see: cursors, transient game state, direct file transfer. You get a direct path and the option of unordered delivery. If the server has to validate, store, moderate or reconcile it, use a WebSocket.
What happens to users who can't connect peer-to-peer?
With TURN configured, ICE picks a relayed candidate and they connect normally. Without it, they get a connection that looks established and carries no media, which is a miserable thing to diagnose from a support ticket. Open Relay covers it with 20 GB free a month.
Should an AI voice agent use WebSocket or WebRTC?
WebRTC for browser and mobile clients — that's OpenAI's own recommendation for the Realtime API. WebSocket stays right for server-to-server integration and control events. If you run the WebRTC endpoint yourself, test restrictive networks and size TURN from what you actually observe.
The bottom line
Ask who owns the data and what it needs from delivery. Not which protocol is better in the abstract.
Between your users, WebRTC. And the data channel is the piece most often skipped in favour of a WebSocket that didn't need to be in the path. Between a user and your server, WebSocket, and there's nothing to reconsider.
If you're running WebRTC, budget for the two things it leans on: somewhere to signal, and a relay for the one connection in five that can't go direct. 20 GB of free TURN on Open Relay and free signalling from Metered Realtime will get you both, and then the peer-to-peer path actually reaches everybody.
Sources: Philipp Hancke, "What kind of TURN server is being used?" (appear.in rtcstats, 10M calls, Aug 2017) · Lumiaho & Singh, "The Big Churn" (callstats.io, Jan 2015–Feb 2016) · MDN: WebRTC connectivity · MDN: Signaling and video calling · OpenAI: Realtime API with WebRTC · Pipecat SmallWebRTCTransport docs
Top comments (1)
thank you for reading, I hope you like the article