DeviceBenchFree packet loss check
Packet loss test that says what a browser can really see
Every request in the burst gets its own square, and the color it ends up is the whole result: cyan for completed inside 400 ms, pale amber for later than that, solid amber for never completed at all. A hundred and fifty of them go out ten at a time, which is about four seconds of steady pressure — enough to expose a link that only misbehaves under load. What the squares count is stated on the panel rather than hidden: a browser sees a request that failed, not a packet that vanished, because the transport underneath resends a lost packet before this tab is told anything at all.
- 100% free
- No signup
- 150 requests
- 10 in flight
- 400 ms late line
Ten requests go out together, then the next ten, until 150 have been sent — around four seconds of steady pressure on your uplink.
- Completed inside 400 ms
- Completed late
- Never completed
- Not sent yet
Nothing has failed yet. When something does, this separates a request that was refused from one that simply never returned, because they point at different problems.
A count of web requests that did not complete, out of 150. A packet that goes missing between your router and the edge is resent by the transport before this page is told anything, so genuine loss usually turns up in the late column rather than the failed one. Zero failures with a fat late column is the signature to look for.
How to check a connection for loss
Three bursts, and the difference between them is what identifies the cause.
Fire the burst and watch the grid fill
Requests leave in waves of ten and each takes its own square, so the picture arrives faster than any number could. What you are looking for is not a single wrong square but a cluster of neighbors going wrong together, because they were in flight at the same moment: that is a burst, and bursts have physical causes. One odd square in a hundred and fifty is noise.
Look at the late column before the failed column
This is the reading most tools never show you. When a packet really is dropped between your machine and the edge, the transport underneath your browser notices and resends it, and your request completes anyway — several hundred milliseconds behind its neighbors. Zero failures with a fat band of late arrivals is the fingerprint of a lossy link, and it looks like perfect health to anything that only counts errors.
Repeat it with the line under load
Start a big upload or a console download and fire a second burst. Loss that only appears the moment the uplink is full is your own connection running out of room, which shows up as late squares first and failures afterwards. Loss that is there whether the line is busy or idle is a physical problem — a cable, a connector, a radio or the segment your provider has you on — and no amount of traffic shaping at home will move it.
Technical specifications
| Burst size | 150 requests, chosen so a single failure reads as 0.67% and the result has somewhere meaningful to sit below the 1% line |
|---|---|
| Requests in flight | 10 at a time. Over HTTP/2 those are ten streams multiplexed onto one connection, not ten separate sockets fighting for the link |
| Cut-off | 1,500 ms per request; anything still outstanding is counted a failure and the next wave goes out regardless |
| Late line | 400 ms. On a link whose median is 20 ms that is twenty times normal, and a recovered retransmission is the ordinary explanation |
| What it cannot observe | A dropped packet. TCP and QUIC both resend one before your browser is told anything, so genuine loss reaches this page as delay |
| Traffic used | Under 5 KB of payload for a whole burst — the file requested is three bytes and the rest is request headers |
| Data kept | None. The grid, the tallies and the failure breakdown live in this tab and disappear on reload |
| Price | Free, no signup, and the burst behaves the same on a phone as on a desktop |
Frequently asked questions
Why can a web page not measure packet loss properly?
Because everything a browser is allowed to send travels over a transport that repairs loss before the page is told. A web request rides on TCP or on QUIC, and both of them notice a missing segment — TCP after three duplicate acknowledgements, or after a retransmission timer that starts at one second and never drops below about 200 ms — and quietly send it again. Your fetch call still resolves with a complete body. It simply resolves later. So the only losses this page can count directly are requests that failed altogether, and the losses it can hint at are the ones that arrived conspicuously late.
What counts as bad packet loss?
One percent, which is far lower than most people expect. The long-standing network design targets for carrying voice are loss under 1%, variation under 30 ms and one-way delay under 150 ms, and voice is the forgiving case because a codec can invent a plausible 20 ms of audio to cover a single missing frame. At 1% you lose roughly one frame every two seconds; at 3% the invented audio starts to sound like what it is. Bulk downloads tolerate far more, which is why a connection can feel perfectly fine for browsing while being unusable for a call.
My result says nothing failed, but my game still rubber-bands.
That is consistent, because a game is not using the transport this page has to use. Real-time games send position updates over UDP, where there is no retransmission by design — a stale update is worthless, so the client extrapolates from the last known position and then snaps you back when a fresh one finally lands. The loss causing that is invisible to any HTTP-based tool including this one. The in-game network graph, which most competitive titles include, is the honest instrument for that particular question.
What does a failed request in this test actually mean?
One of four specific things, and the panel separates them. A timeout means nothing came back within 1,500 ms — the usual sign of a link that has stopped passing traffic rather than one dropping the occasional packet. A network failure means the connection was refused, reset or never established. An error status means the edge answered but declined. And on a laptop, a lid closing or the browser suspending a background tab produces failures that are about your machine rather than your line, which is why the burst is short enough to watch.
Does Wi-Fi cause packet loss?
It causes a great deal of it, and then hides almost all of it from you. The 802.11 standards acknowledge every unicast frame and retry any that goes unacknowledged, typically up to seven times before giving up, so a microwave, a crowded channel in the flat upstairs or plain distance from the router turns into extra milliseconds instead of into missing data. The router statistics page is where the retry counters live. That is also why a cable and a radio can report identical loss here while feeling completely different to use.
How do I measure real packet loss instead?
With a tool that speaks ICMP, from outside the browser. Running mtr, or ping with a hundred packets, gives you loss per hop and shows whether it starts at your router, at your provider's first hop or further out — an ordinary terminal is all it needs. Your router's own status page is the other half of the picture, because a modem reporting CRC errors or a cable segment with a poor signal-to-noise margin is telling you where the packets are dying long before any speed test does.
Does this send anything about me to a server?
Nothing beyond the requests themselves, which are ordinary fetches of one tiny file served from this site. No result is uploaded, no run is associated with you, and the tally of what failed is assembled and displayed entirely inside this tab. Firing the burst costs your connection under 5 KB of payload, which is less than the icon at the top of this page.
About packet loss, and why it hides from web pages
A packet goes missing for one of a few dull reasons: a queue somewhere on the path filled up and the next arrival was discarded, a wireless frame was corrupted past the point of correction, or a physical link is degraded enough to mangle bits. None of those reach your browser as an error, and that is the whole difficulty with this measurement. Everything a page is permitted to send rides on a reliable transport, and reliability is implemented by noticing the gap and sending the missing piece again — TCP does it after three duplicate acknowledgements or after a retransmission timer, QUIC does the same thing in user space with better loss detection. Either way your request completes successfully. It just completes hundreds of milliseconds behind the requests around it, which is exactly why this page counts late arrivals as a separate column instead of folding them into an average.
What the loss does depends entirely on what is running over it. Speech is sent as a stream of small frames — 20 ms each in the codec most calls use — and a receiver missing one will synthesize a replacement from the frame before it, so a single isolated loss is genuinely inaudible. Two or three in a row are not, and that is why the acceptable figure for voice is so much stricter than intuition suggests. Games are stricter still, because they deliberately refuse retransmission: an update about where you were 200 ms ago is worse than useless, so the client guesses and then corrects, and the correction is the rubber-banding everyone recognizes. Before blaming the network for either, it is worth ruling out the equipment at your end: the video call test settles camera, microphone and speakers in one pass, and if audio only ever disappears from one direction or one speaker, the surround sound test walks each channel on its own and rules the wire out entirely.
When a burst here does come back dirty, the next question is where. Loss that appears only while your uplink is saturated is congestion in your own house, and it is fixed by queue management on the router rather than by a bigger plan. Loss that is constant, day and night, at every hour, is physical — a connector, a run of cable, a failing modem, or a shared segment your provider has oversubscribed — and the evidence for that conversation comes from your own router's error counters and from a hop-by-hop tool such as mtr, not from a web page. Two pages here narrow it down further before you make the call: the ping test establishes what your line does when nothing is wrong, and the jitter test shows whether the recovered packets are arriving unevenly enough to break a conversation.
What the burst leaves behind
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
A burst is 150 requests for the same tiny file, each under a URL string invented on the spot so no cache can answer it. They look to a server exactly like any other page load and carry nothing about you that an ordinary request does not. The verdict for each one is tallied in this tab, drawn as a square, and gone the moment you reload.