The quick way: a browser test
The packet loss test on this site runs in any modern browser on a computer, phone or tablet, with nothing to install. It sends 1,500 UDP packets over 30 seconds to the nearest Cloudflare edge and reports loss, ping and jitter, plus a timeline of every packet. Because it uses UDP with no retransmission, it sees loss the way games and calls do, which a download-based speed test cannot.
What a browser test cannot do is tell you where along the route a packet disappeared. For that you need a tool that asks each router on the path in turn.
Windows: ping and pathping
Open Command Prompt and run ping -n 100 1.1.1.1. It sends 100 ICMP echo requests, one a second, and ends with a summary: "Sent = 100, Received = 98, Lost = 2 (2% loss)". To see where loss starts, run pathping 1.1.1.1. It first lists every router on the route, then spends a few minutes pinging each one, and reports a loss percentage per hop.
Mac and Linux: ping and mtr
In Terminal, ping -c 100 1.1.1.1 does the same as the Windows command. For a per-hop view, install mtr (with Homebrew on a Mac, or your distribution's package manager on Linux) and run mtr -rw -c 100 1.1.1.1. It combines traceroute and ping and prints loss and latency for every hop in one report.
Reading per-hop results without being fooled
The most common mistake with pathping and mtr is to see loss at a middle hop and conclude that router is broken. Many routers deliberately give low priority to answering pings about themselves while still forwarding real traffic perfectly. The rule is: loss only counts if it continues to every hop after it. Loss at hop 5 that disappears at hop 6 is just that router ignoring pings.
- Loss starting at hop 1 (your router) and continuing: the problem is inside your home, usually wifi.
- Loss starting at hop 2 or 3 and continuing: your line or the provider's first equipment.
- Loss starting deep in the route and continuing: a congested link between networks or at the destination.
Why the command line and the browser disagree
The ping command sends one small ICMP packet a second. The browser test sends fifty UDP packets a second. A short burst of loss lasting half a second is likely to be caught by the browser test and missed by ping. Some networks also treat ICMP and UDP differently. So it is normal for ping to report 0% while a UDP test reports a little loss, or the reverse. For what your games and calls experience, trust the UDP result; for locating the fault, use the per-hop tools.