The same packet loss percentage means something different depending on what you're doing. 2% loss barely registers on a file download but can make a voice call unintelligible. This calculator gives you the raw number, then rates it against four different real-time and non-real-time use cases at once — instead of one generic "good or bad" verdict for an application it never asked which one you meant.
Packet Loss Calculator
Liveping -n 250 8.8.8.8 on Windows reports "Received" and "Lost" directly.
| Use case | Good below | Poor above | Your result |
|---|---|---|---|
| Online gaming | 0.5% | 1% | — |
| VoIP / voice calls | 1% | 3% | — |
| Video streaming / calls | 0.5% | 2% | — |
| File transfer / browsing | 1% | 5% | — |
Show the working
What Packet Loss Means
Packet loss is the percentage of data packets that never arrive at their destination — dropped by a congested link, a failing piece of hardware, or Wi-Fi interference along the way. It's calculated simply: packets lost ÷ packets sent × 100. The number itself is never ambiguous. What it means for your connection depends entirely on what you're using it for.
You send 250 ping packets and 244 come back. Lost = 250 − 244 = 6. Loss rate = 6 ÷ 250 × 100 = 2.40%. That's poor for gaming and video, borderline for VoIP, and still borderline — not clean — even for a file download; only below roughly 1% would this reading count as good across every use case.
Why the Same Percentage Affects Applications Differently
File transfers and web browsing run over TCP, which automatically detects and retransmits lost packets — the data eventually all arrives, so loss mostly costs a little speed rather than causing visible problems, and rates up to about 5% are commonly tolerated. Gaming, VoIP and live video typically run over UDP, or treat retransmitted data as useless once it arrives late — there's no time to wait for a resend before the next game frame or audio sample is needed. That's why real-time applications tolerate far less loss than file transfers at the exact same underlying network condition.
| Application type | Protocol behavior | Why the threshold differs |
|---|---|---|
| Gaming | Real-time, loss-sensitive | A late game-state update is often discarded rather than used, causing visible rubber-banding |
| VoIP | Real-time, loss-sensitive | Lost audio packets cause clipping and dropouts; there's no time to retransmit mid-sentence |
| Video streaming/calls | Real-time, partially buffered | Some buffering helps, but sustained loss causes pixelation or frozen frames |
| File transfer / browsing | TCP, retransmits automatically | Missing data is resent; loss shows up as slower throughput, not broken files |
Common Mistakes
1.5% loss is a real gaming problem and a non-issue for downloading a file. Always check loss against the specific application you care about.
A 10-packet ping test can easily show 0% or 10% loss by chance. Run at least 100–250 packets, or test for several minutes, for a number worth acting on.
Standard speed tests run over TCP, which retransmits lost packets automatically — they measure throughput, not loss. Use ping or a dedicated loss test to see the real number.
Common Causes of Packet Loss
- Wi-Fi interference or weak signal — one of the most common sources for home connections
- Network congestion — a link carrying more traffic than it can handle drops packets when buffers overflow
- Faulty hardware — a failing cable, port, or router along the path
- Inefficient or unstable routing — a path that crosses more congested or lower-quality links than necessary
| Likely cause | Where to start |
|---|---|
| Wi-Fi | Move closer to the router, switch to a less congested channel, or connect via Ethernet to isolate the variable |
| Local network congestion | Check for other heavy users on the same connection (large downloads, streaming, backups) during the test |
| Hardware | Try a different cable or port; reboot the router/modem |
| Routing beyond your network | Run traceroute/tracert to see where along the path loss begins |
When routing beyond your network is the cause
If traceroute shows loss starting outside your own network, the cause may be an inefficient path, congestion at a specific hop, or another issue along the route. When routing between your ISP and the destination server is part of the problem, a routing-optimization service like GearUP may sometimes route around it.
GearUP cannot fix loss caused by your own local Wi-Fi or a fault inside your home network, since that loss happens before traffic ever reaches the routing service.
Affiliate disclosure: This is an affiliate link. If you purchase through it, Numeros may earn a commission at no additional cost to you. This does not affect our calculations, test results, or editorial conclusions.
Frequently Asked Questions
How is packet loss calculated?
Packet loss rate = (packets lost ÷ packets sent) × 100. For example, if 6 out of 250 sent packets never arrive, the loss rate is 6 ÷ 250 × 100 = 2.4%.
What is an acceptable packet loss percentage?
It depends on the application. Under 1% is generally fine for browsing and file transfer. Real-time applications are stricter: under 0.5% for gaming and video, under 1% for VoIP. Above roughly 5%, most applications show noticeable problems.
Is 1% packet loss bad?
For general browsing or downloads, no — it's within the normal range. For competitive gaming or a video call, 1% is at or past the point where lag, rubber-banding, or dropouts become noticeable.
Why does packet loss hurt gaming more than downloading a file?
File transfers use TCP, which automatically resends lost data until the full file arrives intact. Games need the latest state right now; a late-arriving retransmission of an old game update is often useless by the time it shows up, so it's simply dropped and felt as lag or a rubber-band snap.
What causes packet loss on a home network?
The most common causes are Wi-Fi interference or a weak signal, network congestion on a busy link, faulty cabling or hardware, and inefficient routing between your ISP and the destination server.
Does a speed test show packet loss?
No. Standard speed tests measure throughput over TCP, which retransmits lost packets automatically and hides loss from the result. Use a ping test or a dedicated packet-loss test tool to see the actual loss rate.
How many packets should I test to get a reliable loss reading?
At least 100–250 packets, or a test lasting several minutes. A short 10-packet test can easily show a misleading 0% or 10% by chance, especially if loss happens in short bursts rather than steadily.
Can a VPN or game booster fix packet loss?
It can help specifically when the loss is caused by an inefficient or congested route between your ISP and the destination server, by routing traffic over a more stable path. It cannot fix loss caused by your own Wi-Fi, local network congestion, or faulty home hardware, since that loss occurs before traffic reaches the routing service.
What's the difference between packet loss and latency?
Latency (ping) is how long a packet takes to make a round trip. Packet loss is whether a packet arrives at all. A connection can have low latency and high packet loss, or the reverse — they're independent problems with different causes.
Why do I see "0 lost" but the game still feels laggy?
Zero packet loss doesn't rule out high ping or high jitter, which are separate problems with separate causes. Check a Ping Calculator and Jitter Calculator alongside this one for the full picture.
Why TCP Hides Loss and UDP Doesn't
The gap between "fine for downloads" and "ruins a game" at the same loss percentage comes down to one design decision made decades ago: whether the protocol resends what it loses.
| Protocol | On packet loss | Result |
|---|---|---|
| TCP (web, downloads, most file transfer) | Detects the gap, automatically requests and resends the missing data | The file arrives complete; loss shows up only as reduced throughput, not corruption |
| UDP (most gaming, VoIP, live video) | No automatic retransmission — the application decides what to do, if anything | A lost game-state packet is often simply gone; by the time a resend could arrive, a newer update has already superseded it |
This is also why a TCP-based speed test can show 0% loss on a connection that's actually dropping packets: TCP's retransmission means the test never sees the gap directly, only a throughput dip it may not even notice on a fast connection. A UDP-based tool — or a raw ping, which also runs over ICMP without retransmission — reports the real number instead.
Sources
- General and application-specific packet loss thresholds. Cross-checked against Obkio's guidance on acceptable packet loss, reporting general acceptable loss under 1% and high loss above 5%, with gaming and video good below roughly 0.5% and problems appearing above 1–2%.
- VoIP-specific thresholds. Under 1% loss alongside under 30 ms jitter and under 300 ms round-trip time, consistent with IT community consensus on real-time conferencing quality referencing Cisco deployment guidance.
- TCP vs. UDP retransmission behavior. Standard, well-documented protocol design (RFC 793 for TCP, RFC 768 for UDP) — TCP's automatic retransmission versus UDP's lack of it, which is why the same loss percentage affects them so differently.
- Loss-rate testing methodology. Cross-referenced against PacketProbe's public network-testing methodology for why UDP-based tools reveal loss that TCP-based speed tests mask.
Related Calculators
- Ping Calculator — theoretical and realistic round-trip time
- Jitter Calculator — how consistent your ping is, not just how high
- Gaming Network Quality Calculator — combines this loss figure with ping and jitter into one rating
- Percentage Calculator — general-purpose percentage math
- Subnet Calculator — work out IP ranges and network sizes