What is a packet?
All digital information transmitted across the internet—whether an email, a 4K video stream, a Discord voice message, or a multiplayer game action—is broken down into discrete data units called packets. Under the standard Ethernet transmission protocol, a packet carries up to 1,500 bytes of data (the Maximum Transmission Unit, or MTU), wrapped with headers containing source and destination IP addresses, sequencing numbers, and error-checking checksums.
A single web page is constructed from hundreds of packets; a one-hour video conference streams hundreds of thousands. Packet loss occurs when one or more of these data packets fail to reach their intended destination, disappearing in transit across local hardware, wireless airwaves, or provider routing nodes.
How TCP and UDP handle lost packets
The practical consequence of packet loss depends entirely on the transport protocol used by the application:
- Transmission Control Protocol (TCP) — Reliable Delivery:
Used by web browsers (HTTP/HTTPS), file downloads, email, and on-demand streaming (Netflix, YouTube). TCP is connection-oriented; every received packet must be confirmed with an acknowledgment (ACK). If a packet goes missing, the sender detects the missing ACK and retransmits the lost packet. While you will not see missing text or visual corruption, each retransmission introduces delay. Furthermore, TCP interprets lost packets as a sign of network congestion, automatically shrinking its congestion window (cwnd) and drastically throttling your download throughput. - User Datagram Protocol (UDP) — Real-Time Streaming:
Used by voice calls (Zoom, Teams, VoIP), live broadcasts, and fast-paced online games (Call of Duty, Valorant, Rocket League). UDP is connectionless and prioritizes immediacy over guaranteed delivery. There is no time to request a retransmission—by the time a replacement packet arrives 100 milliseconds later, that frame of video or audio syllable is already obsolete. UDP simply discards the loss and moves on to the next incoming packet.
Symptoms of packet loss across different applications
Because applications handle missing data differently, packet loss produces distinct real-world symptoms:
- Voice and video calls (Zoom, Microsoft Teams, FaceTime): Choppy, robotic, or clipped audio; missing syllables; frozen video feeds; and "network connection unstable" warning banners.
- Online multiplayer gaming: Character rubberbanding (where your player teleports backward to a previous position), unregistered weapon shots, desynchronized opponent positions, and sudden disconnections.
- Cloud gaming (GeForce NOW, Xbox Cloud): Severe video blockiness, macroblocking visual artifacts, and dropped controller input frames.
- Web browsing and large downloads: Noticeable sluggishness and stalling when loading pages, even when your download speed tests at hundreds of megabits.
Why packets get dropped: Physical and network causes
Packets do not simply evaporate; they are discarded or corrupted along the transit path due to specific physical and operational factors:
- Network buffer congestion (Tail drop): When a router, modem, or ISP node receives more data than its outgoing line can transmit, memory queues fill up. Once a buffer reaches 100% capacity, incoming packets are immediately discarded—a process known as tail drop.
- Wi-Fi interference and signal attenuation: Radio signals traveling through air are susceptible to physical obstruction (concrete walls, metal studs), distance degradation, and electromagnetic interference from neighboring Wi-Fi networks, microwave ovens, or Bluetooth peripherals. While Wi-Fi hardware retries corrupted radio frames locally, persistent interference forces the wireless radio to abandon the frame.
- Damaged cables and physical layer faults: A bent or pinched Ethernet cable, corroded RJ45 connectors, loose coaxial cable splitters, or dirty fiber optic connectors cause bit errors. Packets that fail cyclic redundancy checks (CRC) are discarded by network interfaces.
- ISP infrastructure issues: Upstream problems such as failing coaxial line amplifiers on cable networks, excessive signal attenuation on DSL copper lines, or oversold neighborhood nodes that saturate during peak evening hours (7:00 PM to 11:00 PM).
- Firewall and security throttling: Corporate firewalls, intrusion prevention systems (IPS), or misconfigured MTU packet size settings that drop oversized packets rather than fragmenting them.
How much packet loss is acceptable?
| Packet loss rate | Connection health | Real-world impact |
|---|---|---|
| 0% | Optimal / Healthy | Zero lost data. Flawless audio, pristine video conferencing, and perfect multiplayer hit registration. A properly configured wired Ethernet connection should maintain 0% loss under normal conditions. |
| 0.1% – 1% | Acceptable for general use | Imperceptible for web browsing and streaming video. Microsoft Teams enterprise network guidance targets packet loss strictly under 1%. Competitive gamers may notice occasional micro-stutters. |
| 1% – 2.5% | Degraded | Frequent audio distortion, occasional frozen video frames in Zoom/Teams, and noticeable rubberbanding in fast-paced games. Long-distance TCP file transfers slow down significantly. |
| Over 2.5% | Unacceptable / Critical | Severe degradation. Frequent call drops, unintelligible robotic speech, repetitive game desynchronization, and failed file downloads. Indicates a serious local hardware or ISP line defect. |
Note: Packet loss frequently occurs in bursts rather than evenly spaced drops. A connection may operate cleanly for five minutes and then drop 5% of packets during a sudden 10-second interference spike.
How this speed test measures packet loss
Standard web browser speed tests cannot measure packet loss accurately because normal web traffic runs over TCP, which masks dropped packets by retransmitting them in the background. To measure loss directly, our testing engine utilizes modern browser capabilities:
- WebRTC UDP data channel: The engine establishes an encrypted WebRTC data channel running over UDP through a dedicated Cloudflare Realtime TURN relay server.
- 1,000 numbered probe packets: Your browser sends 1,000 sequentially numbered messages in rapid 10-packet bursts through the TURN relay, which bounces them back to your browser.
- Timeout counting: The client waits up to 3 seconds for trailing packets to arrive. Any numbered packet that fails to return is marked as lost, giving an exact, mathematically verified packet loss percentage.
- Why "Not Available" appears: If your network, corporate firewall, or VPN blocks UDP or WebRTC traffic, the test reports packet loss as "Not available" rather than displaying an inaccurate or fabricated estimate.
How to diagnose and isolate packet loss
If your test reveals packet loss, follow this systematic isolation process to determine whether the fault is in your home or on your provider’s network:
- Test over wired Ethernet: Temporarily connect your computer directly to your router with an Ethernet cable and disable Wi-Fi. If packet loss drops to 0%, the fault is wireless interference or distance from the access point.
- Inspect cables and connectors: Swap out old Ethernet patch cables and ensure all coaxial connectors are screwed on finger-tight without severe bends.
- Restart your modem and router: Power cycle both devices to clear memory buffer leaks and re-establish a clean channel lock with your ISP.
- Audit for upstream ISP issues: If packet loss persists over a wired connection directly into your modem, run multiple tests across different times of day. Consistent wired packet loss is actionable proof of an ISP line fault. Follow our full guide on how to fix packet loss to report and resolve line issues with your provider.