Test Your Connection for Packet Loss, Latency and Jitter

Test Your Connection for Packet Loss, Latency and Jitter

NetworkTests measures the things a speed test cannot see. A bandwidth number tells you how much data your line can move; it says nothing about whether packets arrive intact, arrive on time, or arrive at all. Packet loss, latency spikes and jitter are what actually break video calls, voice chat and online games — and they are invisible to a throughput test.

The test runs entirely in your browser. Nothing to install, no account required, and it works on Windows, macOS, Linux, Android and iOS.

What the test measures

  • Packet loss — the percentage of packets that never arrive, measured separately for the download and upload direction so you can tell which way the fault lies.
  • Latency — round-trip time reported as average, median (p50) and 95th percentile (p95), because the tail is what users feel.
  • Jitter — variation in latency between consecutive packets, the metric that determines whether a voice call sounds smooth or choppy.
  • TCP connection timing — DNS resolution, TCP handshake, TLS negotiation and time-to-first-byte against major endpoints.
  • Hop-by-hop path analysis — an MTR-style trace showing loss and latency at every router between you and the test server.

Why UDP, TCP and hop-by-hop together

Most online tools test one thing. Running all three in a single pass is what makes a result diagnostic rather than merely descriptive. UDP measurement exposes raw loss and jitter without TCP's retransmission hiding the damage. TCP timing shows what that loss costs a real application. The hop-by-hop trace then tells you where on the path it happens — your Wi-Fi, your router, your ISP's network, or somewhere further out.

One number tells you something is wrong. Three correlated measurements tell you who needs to fix it.

Share your results as evidence

Every completed test produces a permanent link you can send to your ISP, your IT department or a support forum. Instead of describing a problem in words, you hand over reproducible measurements with timestamps — which is usually what ends the argument about whether a fault exists.

Choose a test server

Tests run against servers in San Jose, Ashburn and Hyderabad. You are routed to the nearest one by default, but testing against a distant server on purpose is a useful way to distinguish a local fault from a long-haul routing problem.