What this test can and can't tell you
This test sends 100 small HTTPS probes, 60 ms apart, and counts any that don't return within 1.5 seconds. Because HTTPS runs over TCP or QUIC, the transport can recover from some losses, so a browser test tends to under-report UDP loss. When it does find loss, take it seriously — a 1.5-second stall would have wiped out dozens of voice packets.
Random loss vs. burst loss
Codecs include packet loss concealment that can paper over a missing 20 ms packet here and there. Several in a row — a burst — leaves an audible gap. The "longest burst" meter above shows the worst run of consecutive losses.
Confirm it from a command prompt
Browsers can't send raw ICMP or UDP. To test the actual path to your VoIP carrier, use the SIP server address from your phone's settings (shown here as sip.example.com):
# Windows — 100 pings, then a per-hop loss report
ping -n 100 sip.example.com
pathping sip.example.com
# macOS / Linux
ping -c 100 sip.example.com
mtr -rwc 100 sip.example.com # install mtr first (brew install mtr / apt install mtr)Loss that starts at one hop and continues to the end of the path is real. Loss on a single middle hop that does not carry through to the last hop is usually just a router that de-prioritizes ping replies — not a problem.
Where packet loss usually comes from
- Wi-Fi interference or a weak signal
- A damaged patch cable, wall jack or switch port
- A modem with signal problems (check its status lights and its signal levels page)
- An overloaded router or firewall CPU
- Congestion or faults on the internet provider's network
Frequently asked questions
How much packet loss is acceptable for VoIP?
Zero is normal on a healthy wired network. Keep it under 1% for business calls. Codecs can conceal occasional random losses, but at 1–2% callers notice clipped words, and bursts of consecutive losses cause audible gaps or dropped calls.
How do I test for packet loss?
Run the test above for a quick check. To test the path to your VoIP carrier, run 100 pings to its SIP server (ping -n 100 on Windows, ping -c 100 on Mac/Linux) and use pathping or mtr to see which hop introduces the loss.
What causes packet loss?
Wi-Fi interference, bad cables or connectors, failing modems or switches, overloaded routers or firewalls, duplex mismatches, and congestion or line faults on the internet provider's network.
Can packet loss be my internet provider's fault?
Yes. If loss appears on a wired computer plugged directly into the modem, and mtr or pathping shows it starting at the first hop beyond your router and continuing to the destination, the problem is on the provider's side. Save the report — it is the evidence the provider's support desk will ask for.
Why does mtr show packet loss on one hop but not the next?
Many routers rate-limit replies to ping and traceroute because answering them is low priority. Loss that shows on a middle hop but not on the hops after it is not real loss for your traffic. Only loss that continues to the final hop matters.
Does packet loss cause dropped calls?
Heavy or sustained loss can. If signaling packets or keep-alives are lost long enough, the phone system may decide the call or registration has failed. Calls that drop at the same interval every time (for example 15 or 30 minutes) are more often a NAT or session timer setting than packet loss.
Sources & references
- IETF RFC 3550 — RTP: A Transport Protocol for Real-Time Applications
- ITU-T G.107 — The E-model (R-factor)
- Bufferbloat.net project
Written by Eric · Reviewed November 2026