TCP vs UDP — what's the difference, and why your site probably already runs on UDP

Here's a surprise. Every textbook says: "the web runs on TCP, UDP is for games." Then you open the Network tab in Chrome, turn on the Protocol column — and see h3.

That's HTTP/3. And it runs on top of UDP. Many big sites already serve pages this way. So the difference between TCP and UDP is trickier than "reliable vs fast." Let's sort it out.

What TCP and UDP do

Both protocols solve one job: deliver chunks of data (packets) from one computer to another. The address is an IP plus a port. The difference is how they deliver.

TCP is registered mail with a delivery receipt. First the two sides "shake hands" and agree. Every packet is numbered. The receiver confirms delivery. A packet gets lost — it's sent again. What comes out is always complete and strictly in order.

UDP is postcards dropped in a mailbox. Send and forget. No handshake, no receipts, no resends. A postcard may get lost, arrive before the previous one, or never arrive. But nobody waits for anybody.

Comparison on five criteria

We'll use a list instead of a table — it reads better on a phone.

• Reliability. TCP guarantees everything arrives. UDP doesn't: what's lost is gone unless the program resends it itself.
• Order. TCP hands data over strictly in order. UDP — as it arrives.
• Latency. Here's TCP's big catch. If one packet is lost, all the following ones wait until it's resent — even if they've already arrived. That's called head-of-line blocking. UDP doesn't have it: the next packet is handled immediately.
• Where you'll meet them. TCP: ordinary sites on HTTP/1.1 and HTTP/2, WebSocket, email, SSH, databases. UDP: video calls, online games, real-time streaming, DNS, and that same HTTP/3.
• Access from a browser. You can't open raw UDP from JavaScript. You can't open raw TCP either — only through HTTP and WebSocket. UDP-like delivery in the browser exists through WebRTC.

Why loss is what matters for calls and games

Picture a video call. A 20-millisecond packet of audio is lost. Which is better?

• Over TCP: everything freezes until the packet is resent. The other person "sticks," then catches up in a rush.
• Over UDP: you miss a tiny sliver of sound. You probably won't even notice.

Old real-time data is useless. A player's position from half a second ago is worthless — you need the fresh one. That's why games and calls happily trade reliability for low latency.

How HTTP/3 ended up on UDP

This is the elegant part. A page needs reliability: a lost chunk of an image has to be resent. So why did HTTP/3 choose UDP?

Because of that head-of-line blocking. In HTTP/2, images, styles and scripts all travel over one TCP connection. Lose a packet of an image — and every file stalls. On bad mobile internet that's noticeable.

So HTTP/3 was built on a protocol called QUIC. QUIC takes bare UDP and rebuilds reliability on top of it: numbering, receipts, resends. But separately for each file. Lose a packet of an image — only the image waits; the styles keep loading. And encryption is built in from the start, like in HTTPS.

There's a bonus for phones too. A TCP connection is tied to an address: switch from Wi-Fi to mobile data and the connection breaks and has to be rebuilt. QUIC recognizes a connection by its own ID, not by address, so a download survives the network switch.

The result is a paradox: UDP isn't an "unreliable protocol," it's a blank slate. On top of it you build exactly the reliability the job needs.

Which one is for you

• Building a site, an API, a chat, an admin panel — use what HTTP and WebSocket give you. That's TCP or QUIC under the hood, and you don't need to think about packets. Server and browser negotiate HTTP/3 on their own.
• Building a video call or voice chat in the browser — use WebRTC. It runs over UDP itself and knows how to drop stale data in favor of fresh.
• Building a browser multiplayer game where every millisecond counts — look at a WebRTC data channel with ordered: false and maxRetransmits: 0. That's nearly UDP. For a turn-based game, plain WebSocket is enough.
• Don't write your own protocol over UDP for a regular app. The reliability you'd be hand-building already exists in TCP and QUIC.

Is UDP faster than TCP?

Not by itself — the packets travel over the same wires. UDP wins on latency: no handshake and no waiting for lost packets. On a perfect network the difference is barely visible.

How do I check if my site uses HTTP/3?

Open DevTools → Network, right-click the table header and enable the Protocol column. h3 is HTTP/3 over UDP, h2 is HTTP/2 over TCP. HTTP/3 is usually switched on by your hosting or CDN.