# WebSocket vs UDP for browser multiplayer

> A browser cannot open a raw UDP socket, so browser games use WebSocket (reliable, ordered, over TCP) or WebRTC data channels (can be unreliable and unordered). Native games should prefer UDP. Choose by who your players are, not by habit.

*NetCraftGames (NCG) by Charging Bull Software. Last updated: 2026-10-03. Canonical page: https://netcraftgames.com/guides/websocket-vs-udp-browser-multiplayer/*

## The short answer

If any of your players use a web browser, you need WebSocket or WebRTC. Native clients on Windows, macOS, Linux, Android and iOS can use UDP, which handles packet loss more gracefully. Many teams run both: UDP for native, WebSocket for web, one authoritative server behind them.

## How they differ

| | Native UDP (ENet, KCP, Unity Transport) | WebSocket | WebRTC data channel |
| --- | --- | --- | --- |
| Runs in a browser | No | Yes | Yes |
| Transport underneath | UDP | TCP | UDP (DTLS/SCTP) |
| Ordering and reliability | Your choice per message | Always reliable and ordered | Configurable |
| Effect of a lost packet | Only that packet | Delays everything behind it | Depends on settings |
| Needs a server | Yes (dedicated) | Yes (dedicated) | Signaling server, peers connect directly |
| Network traversal | Server has a public address | Server has a public address | ICE; may need a TURN relay |
| From an HTTPS page | n/a | Must be `wss://` | Allowed |

## Head-of-line blocking, in plain words

TCP delivers bytes in order. If one packet is lost, later packets wait until it is retransmitted, even if they already arrived. For a turn-based or slower game that is invisible. For a fast action game on a flaky connection it shows up as stutter. UDP lets you drop stale state and send the newest, which is why fast games prefer it.

## Choosing

- **Turn-based, card, puzzle, or slow co-op in the browser:** WebSocket to an authoritative server is the simplest and the most reliable to host.
- **Fast action in the browser:** consider WebRTC data channels, accepting connectivity risk, or keep WebSocket messages small and use client prediction.
- **Native only:** use UDP and skip the browser lane.
- **Both:** run one authoritative server that speaks both transports, or one server per transport.

## What this means on NetCraftGames

- Native UDP games run on the dedicated server lane ([Mirror](https://netcraftgames.com/engines/unity-mirror/), [NGO](https://netcraftgames.com/engines/unity-netcode-for-gameobjects/), [Unreal](https://netcraftgames.com/engines/unreal-engine/), [Godot ENet](https://netcraftgames.com/engines/godot-enet/)).
- Browser WebSocket games run behind a `wss://` gateway ([browser WSS](https://netcraftgames.com/engines/browser-websocket/), [Godot WebSocket](https://netcraftgames.com/engines/godot-websocket/)).
- WebRTC games get signaling rooms ([browser WebRTC](https://netcraftgames.com/engines/browser-webrtc/)); there is no TURN relay, so some networks will fail to connect.

## Mixed content, the classic web trap

A page served over HTTPS may only open secure WebSocket connections. A game that works on `http://localhost` with `ws://` will fail in production unless it uses `wss://`. The gateway terminates TLS so your server does not need certificates.

## Frequently asked questions


### Can a browser game use UDP?

Not directly. Browsers do not expose raw UDP sockets to web pages. They offer WebSocket, which runs over TCP, and WebRTC data channels, which run over UDP-based protocols and can be unreliable and unordered. Native clients can use real UDP, so many games offer UDP for native and WebSocket for browsers.

### Is WebSocket fast enough for a multiplayer game?

For turn-based, card, puzzle and many co-op games, yes. For fast action on unreliable networks it can stutter, because TCP holds later data behind a lost packet. Keep messages small, send state snapshots instead of every event, use client prediction, or evaluate WebRTC data channels if you accept the connectivity trade-offs.

## Sources

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

## Related pages

- [Hosting a browser WebSocket (WSS) game server](https://netcraftgames.com/engines/browser-websocket/): Host an existing authoritative browser game server on NetCraftGames: a Node 24, Python 3.12 or Linux x64 WebSocket server behind a wss gateway.
- [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.
- [WebRTC signaling for browser games, explained](https://netcraftgames.com/guides/webrtc-signaling-for-browser-games/): What a WebRTC signaling server does for a browser multiplayer game, why STUN is not a relay, when TURN is needed, and the offer, answer and ICE flow.