Packet Loss Test
Packet loss is the percentage of data packets that leave your device and never arrive. 0% is the target for gaming and calls. Under 0.5% is usually hidden by the game, 0.5–2% causes rubber-banding and robotic voice, and above 2% competitive play becomes unreliable. A speed test cannot show it, because TCP silently resends lost data.
Sends 1,000 UDP packets and counts how many never arrive
Packets travel over WebRTC through a Cloudflare TURN relay — the same UDP transport games and voice chat use — so this is real UDP loss, not an ICMP estimate. It measures the path from you to the nearest relay, which covers your Wi-Fi, router and ISP: the places most loss happens.
Find out whether your connection is dropping data, not just how fast it is. This test sends 1,000 real UDP packets — the kind games and voice chat use — counts how many never arrive, and measures jitter alongside, in about five seconds.
Last updated
What the numbers mean in a match
Packet loss is the share of data that leaves one end and never reaches the other. A speed test cannot show it, because bandwidth tests run over TCP and quietly resend whatever went missing. Real-time traffic has no time to wait for a resend, so for games and calls every lost packet is a moment where the other side simply does not know what you did.
| Loss | Games | Voice and video calls |
|---|---|---|
| 0% | Nothing to fix. Look at ping and jitter instead. | Clean audio and video. |
| Under 0.5% | Hidden by interpolation; you will rarely notice. | An occasional clipped syllable. |
| 0.5–2% | Rubber-banding, shots that hit on your screen but not on the server, delayed ability casts. | Robotic voice, frozen video frames. |
| 2–5% | Competitive play is unreliable; players teleport and fights resolve unpredictably. | Words drop out; calls become tiring. |
| Over 5% | Disconnects and constant desync. | Calls fail or fall back to audio only. |
Bursts or a steady trickle: what the pattern tells you
After a run with any loss, the panel reports how many separate bursts the drops came in and the longest run of consecutive lost packets. That shape is often more useful than the percentage.
A few long bursts mean the connection briefly stopped carrying anything. The usual causes are close to you: Wi-Fi interference or a device roaming between access points, a router whose buffer overflows when someone starts a large upload, or a cable or DSL line that drops out for a fraction of a second.
Many short, scattered drops point to steady congestion — a link somewhere on the route that is running at capacity and discarding a small share of everything. When that happens mainly in the evening, it is usually your provider's network rather than your home equipment.
Find where the loss happens in three runs
1. Run it on your normal setup. This is your baseline. Run it two or three times; one clean result proves little because loss comes and goes.
2. Run it again on an Ethernet cable plugged straight into the router, with nothing else on the network busy. If the loss disappears, your Wi-Fi is the problem, and the fixes are local: a less crowded channel, 5 or 6 GHz instead of 2.4, or moving closer to the router.
3. Run it on a phone hotspot. If the wired result still shows loss and the hotspot does not, the problem is your router or your fixed-line connection. Restart the router, check the cables and the line into the house, and if it persists, take the results to your provider — a percentage, the time it happened and the fact that it survived a wired test is what gets a ticket escalated.
Jitter: the other half of an unstable connection
Jitter is how much your latency varies from one packet to the next. The test takes 20 latency samples and reports their variation. Under 5 ms is excellent, under 15 ms is fine for any game, and above 30 ms you will feel it as inconsistent aim and stuttering movement even when the average ping looks healthy.
High jitter and packet loss often appear together, because both come from queues: a router or link that is briefly overloaded first delays packets, then starts dropping them. If you see high jitter only while someone else is streaming or uploading, that is bufferbloat, and smart queue management on the router fixes it.
How this test works
Browsers cannot send raw network packets, so the test opens a WebRTC connection through a Cloudflare TURN relay and streams 1,000 small UDP packets through it in batches of ten, then waits three seconds for stragglers before counting what arrived. It is the same measurement the full test on the homepage runs, without the download and upload phases, so both give the same answer on the same connection.
Most online packet loss tools send ICMP echo requests instead. Many routers and providers handle ICMP at a lower priority than normal traffic, so those tools can report loss that your games never experience — or miss loss that they do.
Packet loss questions
What is an acceptable packet loss percentage?
0% is the only result that means loss is not a factor. Below 0.5% is usually invisible because games smooth over the occasional missing update. From 0.5% to 2% you start to see rubber-banding, hits that do not register and robotic voice in calls. Above 2% competitive games feel unreliable, and above 5% real-time traffic is effectively failing.
Why do I get packet loss in games but downloads are fine?
Downloads run over TCP, which notices missing packets and resends them, so a lossy line only makes them slightly slower. Games and voice chat run over UDP, where a lost packet is simply gone and the game has to guess what happened in that moment. The same 1% loss that costs a download a fraction of a second shows up in a match as a teleporting opponent.
Is this test accurate?
It measures real UDP delivery between your device and the nearest Cloudflare relay, which covers your Wi-Fi, router and ISP — where the large majority of loss happens. It cannot see loss that occurs further along, between the relay region and a specific game server. If this test shows 0% but one game still reports loss, the problem is on that game's route rather than your connection.
Why does the test say it could not measure packet loss?
The test needs outbound UDP. Corporate and school networks, some VPNs, hotel Wi-Fi and strict firewalls block it, and some browser privacy extensions block the WebRTC connection it uses. If the test cannot get through, voice chat and many online games will have trouble on that network as well.
How many times should I run a packet loss test?
At least three times, and at the hours when the problem actually happens. Loss is bursty: a single five-second run can land between two interference events and read 0%, or catch one and look worse than your line really is. Consistent loss across several runs is a real fault; loss that appears once is noise.
Can a VPN fix packet loss?
Only when the loss is on your ISP's route to a particular destination, where a VPN can carry the traffic along a different path. It cannot fix loss on your Wi-Fi, your router or the line into your home, because the VPN traffic crosses those too. Run this test with the VPN off first: if it already shows loss, a VPN will not remove it.