Measure real packet loss, latency & jitter using WebRTC

Server

Disconnected

Settings

Presets:

About PacketProbe

PacketProbe measures real packet loss on your internet connection — not just speed or bandwidth. Most speed tests only measure throughput over TCP, which hides packet loss by automatically retransmitting failed packets. That tells you nothing about your connection quality for gaming, video calls, or VoIP.

We use WebRTC unreliable data channels — the same technology browsers use for real-time communication — configured to behave like raw UDP. When a packet is lost, it stays lost, and we count it. This gives you an accurate picture of what your connection actually does under real-time conditions.

What we measure

  • Upload packet loss — packets that never reached the server
  • Download packet loss — packets the server sent back that never arrived
  • Round-trip time (RTT) — how long a packet takes to go to the server and back
  • Jitter — variation in latency, which causes stuttering in real-time apps
  • Late packets — packets that arrived but too slowly to be useful

How it works

Your browser establishes a WebRTC data channel to one of our test servers. It then sends numbered packets at a configurable rate and size. The server records which packets arrive (measuring upload loss) and echoes them back (measuring download loss). The entire test runs in your browser — no software to install.

Packet Loss FAQ

What is packet loss?

Packet loss occurs when data packets traveling across a network fail to reach their destination. On the internet, data is broken into small packets that travel independently. If any packet is dropped along the way — by a congested router, a faulty cable, or a weak Wi-Fi signal — it's considered lost.

Why does packet loss matter?

For real-time applications like online gaming, video calls, and VoIP, even 1-2% packet loss can cause noticeable problems: rubber-banding in games, choppy audio, frozen video frames, and dropped calls. Unlike file downloads (where lost packets are simply re-sent), real-time data has a deadline — if a packet arrives late, it's useless.

What's a good packet loss percentage?

0% is ideal. Under 1% is generally acceptable for most applications. Between 1-2.5% you'll start noticing issues in gaming and voice calls. Above 5% is considered severe — most real-time applications will struggle significantly.

What causes packet loss?
  • Network congestion — routers drop packets when traffic exceeds their capacity
  • Wi-Fi interference — other networks, walls, microwaves, and distance from your router
  • Faulty hardware — damaged cables, failing network cards, or overheating routers
  • ISP issues — oversubscribed nodes, routing problems, or throttling
  • Server distance — more hops between you and the server means more chances for loss
How do I fix packet loss?
  • Use a wired connection — Ethernet eliminates Wi-Fi as a variable
  • Restart your router/modem — clears congested buffers
  • Check cables — replace any damaged Ethernet cables
  • Reduce network load — pause large downloads, limit connected devices
  • Change Wi-Fi channel — use a less congested channel or 5GHz band
  • Contact your ISP — if loss persists on a wired connection, the problem may be upstream
What is jitter?

Jitter is the variation in packet arrival times. Even if no packets are lost, inconsistent timing causes problems. A voice call with high jitter sounds choppy. A game with high jitter feels laggy and unpredictable. Under 30ms jitter is ideal; over 50ms will be noticeable.

Why is this different from a speed test?

Speed tests measure throughput — how much data your connection can move per second over TCP. TCP automatically retransmits lost packets, so speed tests mask packet loss entirely. PacketProbe uses an unreliable (UDP-like) channel that reveals the true loss and jitter your connection produces under real-time conditions.

What do the presets mean?

Each preset configures the test to mimic a specific application's network behavior. For example, the "Gaming (FPS)" preset sends 64 small packets per second with a tight 80ms delay threshold — matching what a competitive shooter actually demands from your connection. This tells you whether your connection can handle that specific use case.