How we test and verify VPNs

The data layer

Every provider we cover has a structured record with more than sixty fields. The fields cover:

plans and prices
refund terms
server network
protocols and security features
logging policy
independent audits
documented incidents
streaming claims
app coverage
support options

Each section of the record carries two things: the date we last verified it and the official URL we verified it against. Pages are built from this record. So a review, a comparison and a deals page can never disagree about a price.

The complete dataset is public on the open data page as JSON and CSV.

What “verified” means

A fact is verified when we read it on the provider’s own pages:

prices on the pricing or checkout page
the money-back window in the refund policy
locations on the server page
protocols and app behavior on the feature or help pages
logging in the privacy policy
audits in the provider’s announcement or the auditor’s report

We never take a number from another review site, and we never fill a gap from memory. If an official page does not state a value, the record says so.

We record prices in US dollars, as shown to a visitor in the United States. We record the effective monthly price, the total billed up front and, when the page states it, the renewal price. A scheduled check reloads the official pages daily. It records any change in the price history and in the changelog on the affected pages.

What we do not claim

We do not publish speed results for any provider yet. Many sites quote a single speed test from one laptop on one day. We think that is close to meaningless. So the speed dimension of our score stays empty until our lab produces repeatable measurements. Until then, every review carries a “not yet tested” notice. The score is calculated from the remaining dimensions, as the methodology explains.

We also do not claim that a VPN works with a streaming service unless we have tested it. When a provider documents streaming support on its own pages, we record that as a claim. We label it as a claim and show the date we read it.

The lab, and what it will measure

Our next stage is an automated test lab. It will be a small set of servers in different regions. Every night, they will connect to each provider through the official Linux apps or through WireGuard and OpenVPN configurations. They will then measure these against fixed reference points:

throughput, which is how much data gets through per second
latency, which is the delay before data arrives
connection time
DNS, WebRTC and IPv6 leaks

We will publish results as rolling 30-day medians, with the raw data available for download. A rolling 30-day median is the middle result over the last 30 days. The methodology will be public before the first result appears. The score will start to include speed only when a provider has at least 30 days of data.

Audits and incidents

We list independent audits with the auditor, the date, the scope and a link to the provider’s announcement or the report.

We also record incidents, such as server seizures, breaches, logging disputes and court cases. Each one gets a date, a short factual summary, a severity level and a source. Medium- or high-severity incidents lower the privacy score for five years. Low-severity events, such as a seizure that exposed no customer data, are documented without a penalty.

Freshness

Every page shows three dates: when it was first published, when its content last changed and when we last verified it. The last two differ on purpose. Each week, we re-check the pages with the oldest verification date. If nothing changed, only the verification date moves. We re-check law and age-verification pages at least every 30 days.