What We Measure Ourselves
One machine, one connection, the same battery of tests through one provider after another, on a schedule. No vendor feed, no press release, and nobody's opinion - including ours.
Measured Performance
Median across cycles. A provider appears after 10 complete cycles, because one cycle of this battery repeats within about ten per cent - wider than the gap between two good providers.
| Provider | Asked for | Cycles | Through the tunnel | Share of our line lost | Latency | Connect | Back after a drop | IPv6 leak |
|---|---|---|---|---|---|---|---|---|
| Mullvad | NL | 20 | 237.7 Mbps | 92.0% | 90.4 ms | 7 s | 38 s | not tested |
| ProtonVPN | NL | 36 | 215.5 Mbps | 94.0% | 91.7 ms | 13 s | 40 s | not tested |
Read the first speed column, not the second. Our line runs at about 3,245 Mbps from Kamatera, Toronto, which is far faster than a home connection. A provider can lose most of that and still be quicker than everything you own, so the percentage is the share we lost on this line - not what you would lose. What does carry over is the first column: it is the ceiling the provider's network could deliver to one client, and comparing it between two rows compares the providers.
“Back after a drop” is not a kill switch test. A kill switch is a feature of a provider’s own application, and we do not run their applications - we run one client for all of them, so whether traffic escapes during a drop would describe our setup and read the same for everyone. What belongs to the provider is the recovery: we take the tunnel down mid-run and time how long until traffic flows again, whether it comes back at all within 45 seconds, and whether it returns through the same exit. Where a share is shown in brackets, that is how often the tunnel came back at all.
“Not tested” means exactly that. The machine the stand runs on has no IPv6 connection of its own, so a provider cannot leak IPv6 to us and we cannot tell one that blocks it from one that carries it properly. Until that changes the column stays empty rather than showing a zero, which would read as a test that passed.
How These Numbers Are Made
- One machine, one line. Every provider is measured from the same host in Kamatera, Toronto, so what differs between two rows is the provider and not the tester.
- A baseline every cycle. The battery runs with no tunnel first, then through each provider minutes later. Overhead is always against that run, never against yesterday's.
- Best of three transfers. A single transfer measures one second of a network's life: two consecutive runs on an idle line disagreed by 38% while this was being built. Throughput is capped by capacity and only dragged down by congestion, so the best sample is the closest to what the link can do.
- DNS is measured, not inferred. The probe resolves names in a zone our own nameserver is authoritative for, so the resolvers that answer are observed arriving rather than guessed from who owns the exit address.
- A failed connection writes nothing. A tunnel that never came up says nothing about that provider's speed, and a zero would say something false.
Last cycle aggregated 1 hour ago.
This Is Not the Same Data as the Results Database
/vpn-results/ aggregates tests visitors chose to share: many machines, many countries, many connections - and a sample that skews toward people who already suspected something was wrong. This page is one machine running a fixed battery on a timer.
Both are honest and they answer different questions. Visitor data says what happens in the wild; the lab says what happens under identical conditions. We keep them in separate stores and publish them as separate figures, because an average of the two would answer neither question and read as though it answered both.
🧰 Measure Your Own Connection
Every test runs entirely in your browser - nothing is stored unless you choose to share the result.
📚 Read next
The longer version: what this test is looking for, and what to do with the answer.
The Measurement Lab - FAQ
What the stand does, what it cannot do, and why the numbers are kept apart from the ones visitors send.
Where does the lab run?
On a virtual server we rent in Kamatera, Toronto, in a datacentre - not on a home connection. That matters when reading the absolute speeds: a datacentre line is faster and steadier than most home lines, so the Mbps figures are higher than you would see. The overhead percentage is the number that survives the difference, which is why it is the one we lead with.
Why so few providers?
Each one needs a paid subscription and a slot in the schedule, and a provider is not published until it has enough cycles behind it. We would rather show three providers with real medians than twenty with a number each taken from one afternoon.
Can a provider pay to look better here?
No, and there is nothing to sell. The stand does not know which provider it is measuring beyond the credentials it was handed, the battery is identical for all of them, and the thresholds were set before the first result existed. If we ever take money from a provider, it will be disclosed on the page in question and it will not touch these numbers.
Why is a provider missing a figure?
Because that particular reading failed and we store nothing when it does. A missing overhead usually means a cycle without a matching baseline; a missing speed means the transfer did not complete. Both are shown as a dash rather than filled in with a zero, which would quietly drag an average down.
Does the lab test the same things as the browser tests?
The overlapping parts use the same methods on purpose - the same speed endpoints, the same DNS measurement against our own nameserver, the same ASN mapping for attributing an exit. What the browser can do that the stand cannot is test the machine you are actually using, which is why the tools exist and why this page ends with a link to them.