Browser Packet Loss Test: Measure P2P Drop Rate

Browser Packet Loss Test: Measure P2P Drop Rate

Packet loss breaks real-time communication in ways latency does not. A dropped packet in a voice call produces a click or silence; in a video stream it causes a freeze or artifact; in a game it causes desync or rubberband lag. Unlike latency, which increases slowly under congestion, packet loss can jump from 0% to 5% suddenly when a link reaches saturation, then drop back to 0% between bursts, making burst testing over a sustained period far more informative than a single-measurement tool.¹

This tester sends probe packets directly between two browser instances over a WebRTC data channel, with probes every 100 ms. Any probe that does not return an echo within 2 seconds counts as a lost packet. Because the traffic follows the actual peer-to-peer path (through your router, ISP, and the remote peer's ISP), the loss reading reflects the real conditions your video call or game session experiences, not the cleaner path to a nearby server.

What causes peer-to-peer packet loss

ISP link saturation is the most common cause of P2P packet loss at home. When your upload bandwidth is fully consumed by another application (a file upload, a video stream, or a background system update), the router drops new packets because the outbound queue is full.² This type of loss affects all connections using the same ISP link simultaneously, not just the WebRTC stream.

How wireless interference produces a different loss signature

Wireless interference produces a different pattern from ISP saturation: short bursts of 2 to 5% loss while the radio retransmits corrupted frames, followed by clean recovery once the interference subsides. Building on this distinction, comparing loss on Wi-Fi versus wired separates radio-layer loss from ISP-layer loss immediately. Run the test on both connections back to back; if loss disappears on Ethernet, the wireless link is the source rather than your ISP.

Simulated loss versus real loss in this tool

This tool displays two loss values: simulated loss from the slider control and real loss from timed-out probes. The simulated loss slider drops outbound packets at the send layer before they enter the network, which is useful for testing how your application handles degradation at a known rate. Real loss counts probes that were transmitted but never echoed back within 2 seconds. Consequently, you can compare the two: if simulated loss is 0% and real loss is 2%, your ISP path is dropping 2% of packets independently of the simulation. Yet if simulated loss matches the slider value exactly and real loss is 0%, your ISP path is clean.

Acceptable packet loss thresholds for real-time applications

Voice calls become noticeably degraded above 1% packet loss. At 3% loss, VoIP codecs skip syllables and callers ask for repetition.³ Video calls tolerate slightly more loss; most codecs recover with a single-frame artifact up to 2 to 3%, but sustained 5% loss breaks adaptive bitrate systems and forces resolution drops.³ Gaming is the most sensitive: 1% loss on a 20 Hz game server tick causes one missed update per 5 seconds, which produces visible desync.⁴ Conversely, file transfers and web browsing tolerate 5 to 10% loss transparently through TCP retransmission, which is why loss often goes unnoticed until real-time applications expose it.⁵

Bufferbloat and queue saturation as a source of burst loss

Bufferbloat describes a condition where a router's outbound queue grows large enough to absorb a substantial fraction of available bandwidth before overflowing.¹ During the overflow, the router drops all arriving packets until the queue drains. This produces a burst loss pattern: zero loss during normal traffic, a sudden 3 to 10% burst when a file upload or video stream fills the queue completely, then a return to zero. The burst coincides with a large RTT spike visible in the sparkline, because packets that eventually drop waited in the queue while RTT climbed.

Pure path loss (a physical link dropping packets due to RF errors or hardware failure) distributes drops randomly and does not correlate with RTT increases. Bufferbloat loss, by contrast, always coincides with elevated RTT because queued packets experience the same delay before dropping. Watching the sparkline for simultaneous RTT elevation and loss accumulation identifies bufferbloat as the source. A router running an Active Queue Management algorithm such as CAKE or fq_codel eliminates bufferbloat by limiting queue depth proactively rather than waiting for the queue to overflow.²

Using RTT and loss together to diagnose bufferbloat

Start a large file upload in a separate browser tab while the loss test runs, then watch RTT and loss spike together: if RTT climbs from 20 ms to 200 ms and loss simultaneously rises above 1%, the router queue is full. Stopping the upload should return both RTT and loss to baseline within a few seconds. If loss persists after RTT recovers, the source is the ISP path rather than the local queue. The correlation between RTT elevation and loss accumulation is the definitive signature of bufferbloat: when both metrics spike together and recover together, the local router queue is the bottleneck rather than the ISP backbone or the remote peer's connection.

Testing application resilience with the simulation slider

For developers verifying how a VoIP client or video conferencing tool handles network degradation, the simulation slider introduces a controlled loss source without requiring a degraded ISP path. Setting the slider to 3% while your application runs on the same connection reveals whether the codec's packet concealment activates at the correct threshold and whether the adaptive bitrate logic responds within the expected time window. The simulation operates at the send layer: probe packets are dropped before entering the network stack, producing a precise application-layer loss condition independent of the actual ISP path quality.

Pairing the loss slider with the artificial latency slider replicates typical evening-congestion conditions: 80 ms of simulated latency alongside 3% loss recreates a congested residential ISP path during peak hours. Running your application through this combined degradation for five minutes tests sustained behavior rather than a transient response. CapyToolkit does not inject any additional network conditioning beyond what the sliders you configure specify, so you remain in full control of the test parameters throughout the session.

Interpreting simulated versus real loss counters

The tool displays simulated loss and real loss as separate counters. When the slider is at 3% and real loss shows 0.2%, your ISP path contributes 0.2% independently of the simulation. If the ISP path itself produces 3% loss alongside the simulated 3%, your application receives 6% total. Tracking both counters separately gives an accurate picture of what the application actually experiences under combined conditions. This separation is particularly valuable when you are evaluating a video conferencing platform's performance: the slider tests how the codec handles a known degradation rate while the real counter reveals whether your ISP path adds additional loss on top of that simulation.

This split view also helps you judge whether a router upgrade will actually help, because only the real counter reflects the path your traffic truly traverses. If the simulated slider matches your target but real loss stays high, the bottleneck is the link itself rather than the application's handling of degradation. Keeping both numbers visible during a sustained test prevents you from mistaking codec concealment for a clean connection when the underlying path is still dropping packets.

When to use this

Run this test when voice calls produce clicks or dropouts, when gaming sessions show rubberbanding that a ping test does not explain, or when you suspect your ISP path to a specific geographic region drops packets under load.

Examples