# WebRTC signaling for browser games, explained

> A signaling server lets two browsers exchange the handshake messages they need to connect directly. It does not carry game traffic. STUN finds public addresses; only a TURN server relays data when a direct path is blocked. Without TURN, some players will not connect.

*NetCraftGames (NCG) by Charging Bull Software. Last updated: 2026-10-03. Canonical page: https://netcraftgames.com/guides/webrtc-signaling-for-browser-games/*

## The short answer

WebRTC lets browsers send data directly to each other, but they first need to swap three kinds of message through some server: an **offer**, an **answer** and **ICE candidates**. That swap is called signaling, and it is not defined by WebRTC, so you build or rent it. Once peers are connected, the signaling server is no longer in the data path.

## STUN, TURN and ICE in plain words

MDN describes the three pieces:

- **ICE** is the framework that tries to connect two peers, using STUN and TURN servers as needed.
- **STUN** tells a client its public address and what kind of NAT it is behind. It does not relay media.
- **TURN** relays all traffic through a server when a direct connection is impossible, such as behind a symmetric NAT. It is the fallback, and it costs bandwidth.

So a game that only has signaling and STUN will connect many players, and fail for the ones behind restrictive NATs or firewalls.

## The message flow

1. Player A asks the signaling server for a room and gets a short code.
2. Player B joins with the code.
3. A creates an offer and sends it to B through signaling.
4. B replies with an answer through signaling.
5. Both exchange ICE candidates through signaling until a working path is found.
6. The data channel opens and play begins, peer to peer.

## Pitfalls

| Pitfall | Why it hurts | Mitigation |
| --- | --- | --- |
| No TURN | Some players cannot connect | Tell players honestly and offer a retry; add TURN when you can meter it |
| Trusting peers | No authoritative server, so cheating and desync are easy | Choose WebSocket to a dedicated server if fairness matters |
| Leaking room tokens | Anyone with the token can join the signaling | Treat tokens like passwords; never log them |
| Large rooms | Every peer connects to every other | Keep rooms small |
| No reconnect plan | Mobile tabs sleep and drop | Re-run ICE and resync state |

## What NetCraftGames provides

Managed rooms of 2 to 16 peers, WebSocket signaling with room-scoped tokens, exact origin checks and a reference browser connector. It does **not** provide TURN or a relay for game traffic. The [browser WebRTC page](https://netcraftgames.com/engines/browser-webrtc/) has the integration steps and limits.

## Frequently asked questions


### Do I need a TURN server for a WebRTC game?

Not for every player, but for some. STUN lets most peers find a direct path, yet symmetric NATs and strict firewalls block direct connections, and only a TURN relay can carry their traffic. If you cannot offer TURN, tell players that some networks may fail and provide a clear retry message.

## Sources

- [MDN: WebRTC protocols (ICE, STUN, TURN)](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols), accessed 2026-10-03

## Related pages

- [WebRTC signaling for browser and Godot games](https://netcraftgames.com/engines/browser-webrtc/): NetCraftGames offers managed WebRTC room signaling for browser and Godot games: offers, answers and ICE only. There is no TURN relay yet.
- [WebSocket vs UDP for browser multiplayer](https://netcraftgames.com/guides/websocket-vs-udp-browser-multiplayer/): Browsers cannot use raw UDP. Compare WebSocket, WebRTC data channels and native UDP for multiplayer games, and pick the right transport for your players.
- [Multiplayer hosting glossary](https://netcraftgames.com/glossary/): Plain-English definitions of dedicated server, headless, UDP, WebSocket, WSS, WebRTC, STUN, TURN, ENet, KCP, manifest, join probe, weighted hour and more.