Free, no signup, tested to 12 regions
Runs entirely in your browser. Your results are never stored on a server.
Run the test to see your verdict.
| Region | Sent | Lost | Loss | Avg RTT | Jitter |
|---|---|---|---|---|---|
| N. Virginia (us-east-1) | – | – | – | – | – |
| Ohio (us-east-2) | – | – | – | – | – |
| Oregon (us-west-2) | – | – | – | – | – |
| Montreal (ca-central-1) | – | – | – | – | – |
| São Paulo (sa-east-1) | – | – | – | – | – |
| Ireland (eu-west-1) | – | – | – | – | – |
| London (eu-west-2) | – | – | – | – | – |
| Frankfurt (eu-central-1) | – | – | – | – | – |
| Stockholm (eu-north-1) | – | – | – | – | – |
| Singapore (ap-southeast-1) | – | – | – | – | – |
| Tokyo (ap-northeast-1) | – | – | – | – | – |
| Sydney (ap-southeast-2) | – | – | – | – | – |
The 12-region test above uses HTTPS requests, where TCP retransmission can quietly hide small amounts of loss. This test is different: it opens a WebRTC data channel to the outboundgateway.com server and sends datagrams that are never retransmitted, in both directions, so lost packets stay visible. Keep this tab in the foreground while it runs.
–
Not run yet
| Sent | – |
| Received | – |
| Missing | – |
| Reordered | – |
| Duplicates | – |
–
Not run yet
| Sent | – |
| Received | – |
| Missing | – |
| Reordered | – |
| Duplicates | – |
Not run yet
| Median RTT | – |
| 95th percentile RTT | – |
| RTT variation | – |
| RTTs over 150 ms | – |
| RTT samples | – |
Packet loss percentage tells you how many packets out of every hundred never arrive. Here is what the numbers mean in practice:
| Packet loss | Verdict | What it feels like |
|---|---|---|
| 0% | Ideal | No lost requests on any tested path. |
| < 1% | Generally fine | Email, browsing, and downloads work normally. |
| 1% to 2.5% | Noticeable | Gaming, streaming, and VoIP calls start to degrade. |
| 2.5% to 5% | Degraded | Calls glitch, games rubber-band, streams drop quality. |
| > 5% | Severe | Most real-time applications break. |
Voice quality standards back these breakpoints: the ITU's E-model, defined in ITU-T G.107, treats voice as highly sensitive to even small loss rates, while ITU-T G.114 recommends keeping one-way latency under 150 ms for real-time voice.
Packet loss is the percentage of data packets sent across a network that never arrive at their destination. Browsers cannot send ICMP ping packets, so this test measures HTTP requests to regional cloud endpoints: any request that returns no response within three seconds counts as lost. Even 1% loss degrades VoIP calls and online games; above 5%, most real-time applications become unusable.
Your traffic takes a different physical path to every destination: different peering agreements, submarine cables, and ISP handoffs. Packet loss is usually path-specific. Your line can be clean to Frankfurt and lossy to Singapore because a single transit hop in between is flaky.
A single-target test measures exactly one path and can miss the problem entirely. Testing 12 AWS regions at once shows you whether your loss is everywhere (your local network or ISP), regional (a peering or routing issue), or isolated to one route.
If every region shows loss, start with your router and WiFi. If only distant regions show loss, the problem is likely outside your home network. Read exactly how the measurement works.
Click Start Test above. For 15 seconds the tool sends small requests to 12 AWS cloud regions and counts any request that gets no response within 3 seconds as lost. You get a live round-trip-time chart, a per-region table, and a plain-English verdict. For command-line alternatives you can also run ping or mtr against a known server.
For email, browsing, and downloads, 1% loss is rarely noticeable. Real-time applications are far more sensitive: the ITU-T G.107 E-model shows voice quality degrading measurably once loss approaches 1%, and online games and video calls start to stutter in the 1% to 2.5% range. Above 5%, most real-time applications become unusable.
Yes. The test measures whatever path your browser uses, WiFi included. WiFi adds its own loss sources, such as interference, distance from the router, and congestion from other devices. Run the test on WiFi, then again on a wired connection, and compare the two results to isolate WiFi-specific loss.
Latency is how long a packet takes to arrive. Packet loss is when packets never arrive at all. Jitter is the variation in latency between consecutive packets. A connection can be fast (low latency) yet lossy, which breaks games and calls in a way raw speed never predicts. ITU-T G.114 recommends keeping one-way latency under 150 ms for voice.
Work from the cheapest cause outward: restart your router, move closer to it or switch to a wired link, pause heavy downloads and backups, disconnect your VPN to see if it is the culprit, and swap cables if hardware is aging. If loss persists on every region in this test, the problem is usually your local network or your ISP's last mile. Re-run the test after each change.
No, and we say so plainly: browsers cannot send ICMP ping packets. This test measures small HTTPS requests to regional cloud endpoints, counting a request as lost when no response arrives within 3 seconds. That approximates what your applications actually experience, often better than ICMP, which many routers deprioritize. This page also offers an optional UDP test that uses WebRTC data channels to send datagrams that are never retransmitted, so both directions are measured separately. See How this test works below for the full methodology.
Most packet loss testers stay quiet about what they actually measure. Here is everything this one does, including its limits.
The tool sends streams of tiny HTTPS requests to 12 public AWS S3 regional endpoints. A request counts as delivered when any response, of any HTTP status, arrives within 3 seconds. A request counts as lost when no response arrives within that window. Round-trip time (RTT) is measured from dispatch to the moment response headers arrive, and jitter is the mean absolute difference between consecutive successful RTTs.
Browsers deliberately cannot send ICMP echo packets; no web page can. So like every browser-based tester, we infer loss at the application layer. That is not a weak substitute: ICMP is often deprioritized or rate-limited by routers, while HTTPS traffic travels the same path and priority as your real applications. What you see here is what your apps experience, which for debugging is usually the more useful signal.
The second test on this page measures real datagram loss instead. It opens a WebRTC data channel configured for unreliable delivery (no retransmits, no ordering), so a dropped datagram stays dropped and shows up as loss, with upstream and downstream measured independently. Round-trip time comes from datagrams the server echoes back, not from synchronized clocks, so there is no one-way latency figure. WebRTC message loss is close to, but not identical to, raw IP packet loss, because the transport can fragment and bundle messages. The test needs outbound UDP to be allowed: on networks that block it, the connection simply fails to open, which is itself a useful finding for real-time apps. This mode runs against a single endpoint rather than 12 regions, runs from a background tab get flagged as suspect, and its numbers are not directly comparable with the HTTPS test above.
N. Virginia (us-east-1), Ohio (us-east-2, standing in for a central-US region since AWS has none), Oregon (us-west-2), Montreal (ca-central-1), São Paulo (sa-east-1), Ireland (eu-west-1), London (eu-west-2), Frankfurt (eu-central-1), Stockholm (eu-north-1), Singapore (ap-southeast-1), Tokyo (ap-northeast-1), and Sydney (ap-southeast-2). We probe a deliberately nonexistent bucket name on each endpoint, which returns a small, fast error response in-region.
The test runs entirely in your browser. No results, IP addresses, or identifiers are sent to or stored on our servers. A finished result is encoded into the share URL only when you copy it, and the address bar is updated locally without a page reload.
If you route outbound traffic through an IP-restricted vendor, a fixed outbound IP removes one variable from the debugging. OutboundGateway provides two static EU IPs with automatic failover.