TCP vs UDP: what's the difference and when does it matter?

TCP and UDP are two ways to talk over the internet. Every connection your device makes — whether to load a web page, watch a video, or play a game — uses one or the other (or sometimes both, depending on the protocol layer above).

Most users never have to know the difference. But the difference shapes how the internet feels: why some things stutter, why others feel instant, why a 1% packet loss kills a video call but barely affects a download.

Here's the practical version.

The two-line summary

TCP (Transmission Control Protocol) — reliable. Every byte arrives in order, or you'll know about it. Best for things that must be correct.
UDP (User Datagram Protocol) — fast and best-effort. Some packets may be lost or reordered. Best for things that must be timely.

You can't have both at once at the protocol level. The choice is a tradeoff: reliability costs latency, and latency costs reliability.

What TCP gives you

When you open a TCP connection, the protocol guarantees:

Reliable delivery. Lost packets are detected and retransmitted automatically.
In-order delivery. Packets that arrive out of order are reassembled before being handed to the application.
Connection-oriented. A handshake establishes the connection; both ends know about each other.
Flow control. TCP slows down if the receiver can't keep up.
Congestion control. TCP slows down if the network gets congested, and ramps back up as conditions improve.

The cost: every packet must be acknowledged, retransmissions add delay, and the handshake itself takes a round-trip before any real data flows.

For a typical TCP connection: SYN → SYN-ACK → ACK = three packets and one round-trip just to start. Then data can begin.

This is why TCP feels heavy on slow connections. Every loss or delay propagates through the protocol's machinery.

What UDP gives you

UDP is the opposite: minimal protocol, minimal guarantees.

No connection. Just send packets to an IP and port; hope they arrive.
No retransmissions. Lost packets stay lost.
No ordering guarantee. Receiver gets packets in the order they arrived.
No flow control. You can flood your own connection.
No congestion control. UDP-based applications must implement this themselves if they want it.

The cost is: everything's the application's problem. The benefit is: no protocol overhead, no waiting for retransmissions, no "head-of-line blocking" where one slow packet stalls everything behind it.

UDP is fast.

When you'd want each

TCP wins for…

Web browsing. HTML, CSS, JavaScript must arrive correctly and in order.
File downloads. Even a single corrupted byte can ruin a binary.
Email (SMTP, IMAP). Messages must be transferred without corruption.
SSH, remote shells. Lost characters would make the session useless.
Most APIs built on HTTP/HTTPS.

UDP wins for…

DNS queries. Tiny payload (one packet). Reliability is overkill — if it gets lost, retry. The retry's cheaper than the connection setup TCP would need.
Video and voice calls. Late packets are useless; better to drop them and continue. A 50ms-late frame in a Zoom call is worse than a missing one.
Real-time gaming. Same idea — if your "where am I?" packet is 100ms old, throw it away and use the newer one.
Live streaming protocols like RTP.
Some VPN protocols. WireGuard runs on UDP for performance. OpenVPN can use either, prefers UDP for speed.

The HTTP/3 plot twist

For three decades, the web ran on HTTP over TCP. That changed quietly with HTTP/3, which runs HTTP over a new transport called QUIC — and QUIC runs on UDP.

Why? Because TCP's congestion-control machinery and head-of-line blocking, while reliable, couldn't keep up with the demands of modern multi-stream connections. QUIC re-implements reliability and ordering on top of UDP, but smarter — per stream, not per connection. A single lost packet on a CSS file no longer blocks the JavaScript file from finishing.

QUIC + HTTP/3 is fundamentally a way to use UDP for the things TCP traditionally did, while sidestepping TCP's downsides at the operating system level. As of 2026, around 30% of web traffic is HTTP/3 — a steady, ongoing migration.

Common confusions

"UDP is unreliable so my video call drops a lot." UDP doesn't make networks more lossy. It just doesn't try to fix loss when it happens. If your video calls are drop-prone, the underlying network is the problem; UDP is the right choice for the workload.

"TCP is more secure than UDP." Neither is more secure. Security comes from the protocol layer above (TLS, DTLS, application encryption). TCP and UDP are both equally observable to an eavesdropper.

"My firewall blocks UDP." Some restrictive corporate firewalls block UDP except for specific ports (like 443 for QUIC, 53 for DNS). Most home firewalls do nothing of the kind. If a UDP-based app fails on a restrictive network, that's the firewall — try the app's TCP fallback if it has one.

"UDP doesn't work over the internet." False but persistent. UDP works over the internet just fine — DNS, video calls, gaming, and a third of web traffic now run on it.

How to tell which a connection is using

Most user-facing tools don't surface this, but if you're poking around:

netstat on macOS/Linux shows protocols per connection.
Resource Monitor on Windows shows the same.
Wireshark shows packet-level detail, including transport protocol.

For a typical browser session in 2026, you're using TCP for HTTP/1.1 and HTTP/2 sites, UDP/QUIC for HTTP/3 sites. The browser handles fallback if QUIC fails.

Quick FAQ

Is one faster than the other? For small transactions: UDP is faster (no handshake). For large transfers over reliable networks: TCP and UDP-based protocols are similar; congestion control matters more than the underlying transport.

Does UDP cost more bandwidth? Less, actually — no acknowledgment packets. UDP has the lowest overhead of any IP protocol.

Why do we still use TCP in 2026? For most workloads, "correct and slightly slow" is preferable to "wrong but fast." TCP is the right answer for the vast majority of internet applications. UDP fits the niches where latency matters more than reliability.

What's the difference between UDP and "raw IP"? UDP adds two things on top of IP: source/destination port numbers (so multiple apps can use the same IP), and a basic checksum. That's it. UDP is the thinnest possible useful transport.

TL;DR

TCP = reliable, ordered, slower.
UDP = best-effort, fast, lossy.
Web browsing, email, downloads → TCP (mostly).
DNS, video calls, gaming, modern HTTP/3 → UDP.
The right answer depends on whether you'd rather wait or lose data — and modern protocols (QUIC) are getting good at picking smartly per-stream.

If someone tells you UDP is "broken" or "less safe," they don't know what they're talking about. Both protocols are correct tools for different jobs.