How This Test Measures Your Connection

This page describes exactly what PingPacketTest.com sends, how it turns the replies into the three numbers on the front page, and — in the last section — what those numbers cannot tell you. If you only read one part, read that one.

What the test actually sends

The browser opens a WebRTC DataChannel to one of the measurement servers and sends small packets over it. The channel is configured ordered: false and maxRetransmits: 0, which is the part that matters: the browser is told never to resend a packet and never to hold one back waiting for a missing predecessor. That makes it real UDP, the same transport almost every online game uses for its live traffic.

Each packet carries a sequence number and the time it left, padded to the packet size of the game you selected. The server does one thing with it: it echoes it straight back, unmodified. The round-trip time is therefore measured entirely in your browser, against a single clock, so there is no clock-synchronisation error between the two machines. A packet whose echo never arrives is counted as lost.

Why a speed test cannot answer this question

A browser speed test measures bandwidth over TCP. TCP is built to hide exactly the problem you are looking for: when a packet is lost, TCP silently retransmits it, and all you see afterwards is a slightly lower throughput figure. The loss happened, the connection recovered, and the number at the end of the test says "92 Mbps".

A game does not do that. It sends a position update at a fixed rate and moves on. If one update is lost it is not resent, because by the time it arrived it would describe where you used to be. That is why a connection can pass every speed test and still rubber-band: the bandwidth is fine, individual packets are not arriving. Measuring over an unreliable transport is the only way to see it, and it is the reason this tool exists.

Tick rate: why the game you pick changes the test

A game server does not process input continuously. It advances the world in fixed steps — ticks — and a client sends and receives at a matching rate. Counter-Strike 2 runs its official servers at 64 ticks per second, Valorant at 128, Apex Legends at 20. That rate determines both how often packets cross your line and how much a given delay costs you: at 128 ticks a 60 ms round trip is nearly eight server updates, at 20 ticks it is barely one.

Picking a game here is therefore not a label on the results. It changes the send rate and the packet size of the test itself, so the traffic pattern on your line matches what that game actually produces. The rate used for every supported title, where it came from, and whether it is a developer figure or an estimate, is listed in the tick rate database — and it is marked as an estimate wherever it is one.

Where the measurement servers are

There are four: New York, San Jose, Frankfurt and Singapore. Your browser measures against the nearest one by default, and you can switch manually to check a specific route — a European line to a Singapore server is a legitimate thing to test if that is where you play. The server you measured against is named on every result, because a ping figure without a destination means nothing.

How the numbers are produced

The first second doesn't count. Every test opens with a one-second warm-up: packets are sent, but nothing they do is counted or charted. Establishing a connection has a cost — the first packets across a path are slower, and the route can still change while they travel — and that cost belongs to setting the connection up, not to your line. This is standard practice in network measurement, and it is stated here rather than left implicit, because a warm-up that isn't disclosed is just a flattering number. It applies at the start of a test only: if your connection degrades or drops mid-test, that shows up in full.

Ping is a median, with the full range drawn behind it. The chart plots one point per 100 ms. At a game's tick rate that point can cover many packets — at 128 Hz, about thirteen — so it shows their median, which keeps the line readable. The shaded band behind the line is the lowest and highest packet in that same slice. Nothing is smoothed out of existence: if one packet in a slice took 400 ms, the band reaches 400 ms even where the line stays flat. Zooming out groups points further, and a group takes the highest value it contains, so a spike never disappears as you zoom out.

Packet loss is never averaged. Loss is a list of events, not a measurement series. One lost packet draws its marker at full strength at every zoom level. A packet counted as lost that still arrives afterwards has its loss taken back — it was late, not lost.

Jitter is measured over fixed one-second windows (the standard deviation of the round-trip times in each second, averaged across the test). Measuring the gap between consecutive packets instead would make the figure depend on the game you picked, because consecutive packets are 7.8 ms apart at 128 Hz and 100 ms apart at 10 Hz. Fixed windows mean the same line reports the same jitter at any tick rate.

A round trip over 1000 ms is counted as lost. For a game that is the honest reading: a packet that late has no value left.

How the verdict and the percentile are worked out

The verdict takes the worst of the three numbers, not the average. A connection with a 20 ms ping and 2 % packet loss is not a good connection, and averaging that away would be exactly the kind of flattery the rest of this page removes. The metric that decides the verdict is also the one named in the sentence, so you can check it against the chart.

The jitter thresholds are derived from the tick rate, not chosen. A server that ticks at 128 Hz updates every 7.8 ms; at 30 Hz, every 33 ms. Jitter beyond one tick interval means your inputs can no longer be placed in a predictable tick, so the limit for "good" is half a tick and the limit for "playable" is one tick. Both are capped at 15 ms and 30 ms respectively — for a 10 Hz game the tick maths alone would call 90 ms of jitter fine, which is true of the tick rate and useless to a human.

The ping thresholds are a judgement, and this is what they are. Under 30 / 60 ms for 100 Hz and faster, 40 / 80 ms at 60–64 ticks, 60 / 100 ms at 30 ticks, 80 / 150 ms below that. Higher tick rates resolve smaller time differences, so the same ping costs more of them. For packet loss the threshold is the same everywhere: anything above zero is "will drop inputs", above 1 % is "not good enough". A dropped packet is a dropped input at every tick rate.

The percentile compares you against tests run here, not against the internet. "Better than 72 % of tests run here to Frankfurt" means exactly that: of the finished tests stored for that measurement server, 72 % had a higher ping than yours. It is not a statement about all connections in a country — people who run a packet loss test are not a random sample, and many of them arrive precisely because something is wrong. The table is rebuilt once a day from finished tests of at least ten seconds over the last year, and a server with fewer than 500 stored tests gets no percentile at all rather than a shaky one.

What the NAT type line means

While the test runs, the status row above the chart names the kind of network path that carried it. This is not a guess and not a lookup: it is the type of the ICE candidate pair the connection actually nominated — host for a direct public path, server-reflexive for a connection through a NAT that let a direct route form anyway, and relay for one that could only be established through a relay server in the middle. They are shown as Open, Moderate and Strict because those are the words the console menus use, and because they line up in practice.

Two honest limits. A browser cannot read the NAT type a games console prints in its own settings, so this is the equivalent observation rather than that number. And when UDP is blocked entirely the line says so instead of naming a type, because in that case no candidate pair was ever established. The NAT type page explains what to do with each result.

How dropouts and availability are counted

On a run of a minute or more, the tool starts reporting what the line did over that time rather than only what it is doing now. A dropout is a stretch of at least one full second in which every 100 ms window lost at least one packet. Availability is the share of the measured time that was not inside such a stretch.

Two deliberate choices behind those definitions. The one-second floor exists so that individual lost packets are not dressed up as outages — a single missing packet is reported as packet loss, which is what it is. And availability is a share of measured time, not of packets: a line that answers 99.98 % of the time but goes silent for four seconds twice an evening is the exact fault a game notices and an average would hide. The figures are computed once, when the test finishes, and stored with the result, so the summary on a shared page and the one in the exported PDF are always the same numbers.

How the load test differs from everything above

Everything described so far is passive: the tool sends small packets and waits, and the connection behaves exactly as it would with the tab closed. The bufferbloat test is the one exception on this site, and it is worth being explicit about it. That test deliberately saturates your connection — ten seconds in each direction — because latency under load cannot be measured without load. It therefore never starts on its own, and it asks first.

It runs in four phases: five seconds idle to establish a baseline, ten seconds with our server sending as fast as your line will take it, two seconds to let the queue drain, then ten seconds with your browser sending. The probes travel over the same peer connection as the load, so they pass through the queue that is being filled. The grade is the increase in median round trip against the idle baseline, the worse of the two directions decides the overall letter, and the 95th percentile is reported next to it because that is the moment a player actually notices.

Three limits belong here rather than on that page alone. The load is capped at ten seconds and 25 MB per direction, enforced by the measurement server and not by the browser; where that was not enough to fill the line, no grade is given at all instead of a flattering one. The test is refused outright on a relayed connection, because it would be measuring the relay — and because relayed traffic is metered, which is the reason the refusal is absolute rather than a warning. And a run is abandoned if the tab goes to the background, since a throttled tab measures the browser's power saving rather than the line.

What this test cannot tell you

Every measurement has a boundary. These are ours, and none of them is a reason not to run the test — they are the difference between a result you can act on and a result you can only quote.

It measures the path to our server, not the path to your game server. If the route to Frankfurt is clean and your game still stutters, the problem may sit on the leg between your provider and that game's data centre, which no browser can reach. What a clean result here does establish is that your own line, your router and your provider's first hops were healthy at that moment — which is precisely the half an ISP is responsible for.

A round trip cannot tell you in which direction a packet was lost. We send a packet and wait for its echo. If it never comes back, something dropped it — on the way out or on the way home, and there is no way to distinguish those from one end. Tools that claim a direction from a browser are inferring it, not measuring it.

It does not tell you which hop is at fault. This is an end-to-end measurement, not a traceroute. It proves that loss or delay exists on the route as a whole. Locating it needs access to the hops in between, which a browser does not have and which is why the report you can export is addressed to the party that does.

If UDP is blocked, the test falls back to a TCP connection. Some corporate networks and VPN configurations do not let a WebRTC DataChannel establish at all. Rather than showing nothing, the test then measures over a WebSocket — which is TCP, and therefore retransmits. On such a connection the ping figure is still meaningful but the packet loss figure will read lower than reality, because the retransmissions are hidden from us in exactly the way described further up. The same applies when your connection can only be established through a relay server (TURN): the route is then longer than your real path, and the ping includes that detour.

It measures your connection as it is right now, including what else is using it. A download in another window, a console updating in the background or someone else in the house streaming will all show up as your result. That is a feature when you are hunting bufferbloat and a trap when you are not aware of it. If a test looks bad, run it again with everything else quiet before drawing conclusions.

The browser is not a real-time environment. Timing is driven by a dedicated Web Worker rather than a plain timer on the main thread, precisely so that rendering work does not distort the send rate — but a browser still schedules at the mercy of the operating system. A heavily loaded machine, an aggressively throttled laptop or a background tab can add a millisecond or two of jitter that is yours, not your provider's. This is small compared with any real network fault, and it is not zero.

It is not a bandwidth test and cannot substitute for one. The packets here are tiny by design. A connection can pass this test perfectly and still be too slow to download anything, and that is not a contradiction — they are different questions.

Nothing on this site is a random sample of the internet. The people who run a packet loss test are overwhelmingly people with a problem. Every comparison we publish — the percentile line, the statistics page — says "of tests run here" and means it. Any figure from this site quoted as "the average connection in country X" would be wrong, and we would rather say so than let it happen quietly.

Where to go from here

The tick rate database lists every supported game with the rate this test sends, its source, and whether it is verified or estimated. Aggregate statistics show how the tests run here are distributed, with the same caveat as above attached. Live statistics show what is being measured right now, about this project explains who runs it, and the test itself starts the moment you open it.

Every finished test can be exported as a PDF report — timestamps, route, chart and a short version of this methodology — for sending to a provider. There is no IP address in it.

Questions, corrections or a methodology mistake you have spotted: info@pingpackettest.com. Corrections are welcome and get made.