How We Test VPNs

What this page covers

See the process, the evidence, and the limits

This is the working methodology behind our current VPN reviews and Best VPN Services comparison. It explains what we buy and inspect, how we calculate speed results, what counts as a streaming result, how we handle leak checks and refunds, and where our evidence stops.

Paid review process

Our VPN review workflow

The current ranked providers were not scored from feature pages alone. We purchased a public plan from each provider, worked through the account and app experience, ran recorded checks, reviewed official documentation, contacted support where it helped resolve a buying question, and submitted a refund request after testing.

1. Select a relevant provider. We choose services that represent meaningful buyer needs, technical approaches, or market positions.
2. Purchase through the public customer path. We record the plan, checkout terms, billing visibility, renewal information, and material add-ons; our VPN cost and renewal study publishes the normalized price fields and formulas.
3. Set up the real account and apps. We review onboarding, downloads, Windows app behavior, and secondary platforms when they are part of the documented workflow.
4. Run the recorded checks. Speed, protocol, IP/DNS/WebRTC, kill switch, split tunneling, streaming, and relevant advanced features are tested or reviewed according to what the product actually offers.
5. Check the buying-risk details. We use official policies and support answers to clarify pricing, renewal, platform limits, cancellation, refunds, and feature restrictions.
6. Close the workflow honestly. We submit the refund request, record the outcome we can actually observe, keep unresolved outcomes unresolved, and publish with dated limitations.

Evidence Levels 1–5

Our Evidence Level describes the strongest access achieved for a review. It is not a quality score, and a higher number is not automatically better. A Level 4 review can still rely on Level 1 official documentation for facts that are better answered by a policy or support page.

All nine VPNs in our current ranked comparison reached Level 4. We do not label any of those reviews as Level 5.

Recorded conditions

Test environment and session controls

Our current VPN work uses a Latin America-based consumer test environment, with Windows 10 as the primary desktop platform. Speed sessions used Wi-Fi or cable according to the provider’s recorded research session, and the individual reviews preserve those network details where they matter. Android and browser checks were added when relevant; untested platforms are described from official documentation rather than presented as hands-on findings.

We try to keep a provider’s speed checks within the same session conditions: same connection, similar time window, no deliberate heavy background downloads, and documented protocol or feature settings. We do not claim that every review used an identical number of routes, repeated runs, secondary metrics, or connection type. That difference is part of the evidence record, not something we smooth over later.

Test matrix

What we check in a VPN review

The matrix is intentionally broader than a speed benchmark. A VPN is also an account, an app, a billing relationship, a set of privacy claims, and a collection of platform-specific controls. We test the parts most likely to change a buying decision and label unavailable or untested features instead of treating a missing test as a pass.

Measured performance

How we run and calculate VPN speed tests

The current comparison contains 268 recorded Speedtest by Ookla Windows app rows: 86 no-VPN baseline records, 117 VPN route records, and 65 protocol-comparison records. Every row contains ping, download, and upload. Packet loss, jitter, data usage, and exact timestamps are secondary fields and were not captured consistently enough across the full first cycle to force into one universal score.

Baseline, route, and protocol records serve different jobs

A baseline describes the connection without the VPN. A route record describes the VPN-on performance for a selected location and protocol. A protocol comparison holds the destination more tightly and changes the protocol or connection mode so we can see how the app behaves under a more controlled comparison. Those rows stay separate in the underlying dataset.

If your question is which tunnel to choose rather than how our full review system works, see our VPN protocols comparison. It uses the 65 protocol-comparison records to examine WireGuard-family versus OpenVPN results, OpenVPN UDP versus TCP, provider-specific modes, and availability boundaries.

Where a route has repeated runs, we average those runs before using the route in a provider-level comparison. Some earlier sessions contain fewer repeats or a smaller route set. We use the recorded run that exists, mark the lower repeatability as a confidence limitation, and never manufacture a missing second run.

The screenshots show additional secondary Speedtest fields. If a secondary field was not entered in the consolidated research row, we leave that field missing rather than backfilling it from an image after the fact.

Our current speed index

Raw Mbps alone would favor providers tested on the faster baseline connection. Retention percentage alone could understate the practical value of a high-throughput result. The index used in the current Best Picks balances both:

For each provider, we average the recorded no-VPN baseline download and upload values for that review session. Each VPN route is reduced to its recorded run average when repeats exist. Download retention is the route download divided by the provider baseline; upload retention is calculated the same way. We then use the median across the provider’s ranked routes.

Practical throughput score = median route download ÷ 300 Mbps × 100, capped at 100. Final speed index = (0.65 × median download-retention score) + (0.25 × practical-throughput score) + (0.10 × median upload-retention score).

Differences below one index point are treated as technical ties. We resolve those first by evidence completeness and repeatability, then by practical throughput. Ping and packet loss can still change our written caution about a provider, but they are not forced into the universal index because route conditions and measurement completeness differ across the first cycle.

See the current nine-provider speed ranking for the result of this formula. For a repeatable at-home comparison, use our VPN speed test and speed-loss calculator; it calculates throughput retention and latency changes locally in your browser and includes the sanitized 268-row speed dataset behind this cycle. This methodology page stays focused on how ReviewsAlly produces review evidence.

Leak checks and safety controls

How we check IP, DNS, WebRTC, kill switch, and split tunneling

A VPN can connect successfully and still route something in an unexpected way. Our leak-oriented workflow therefore checks the public IP change and uses BrowserLeaks DNS and WebRTC tools while the VPN is active. IPv6 is recorded when it is part of the captured check. We compare the visible result with the original network information privately and avoid publishing the real baseline IP or unnecessary local details.

Kill switch and split tunneling are different questions. For a kill switch, we care about what happens to traffic when the tunnel is interrupted or the relevant control is engaged. For split tunneling, we care about whether selected apps, sites, or rules take the VPN or non-VPN path as configured. Availability, manual behavior, and OS support are recorded separately when the evidence requires it. Our VPN split-tunneling guide publishes the privacy-preserving dual-route check and the dated Windows findings behind that distinction.

For the full reader-facing failure test, see our VPN Kill Switch guide. It shows the Windows forced-interruption procedure, separates unexpected drops from manual Disconnect, and explains when a result is Pass, Fail, or Inconclusive.

These are consumer-facing configuration checks, not a source-code review, penetration test, cryptographic audit, or independent inspection of a provider’s full network. If a documented check does expose the original resolver or public IP, that finding is kept in the review rather than averaged away.

Playback workflows

How we test VPN streaming

Each of the nine ranked providers has five rows in the current streaming matrix: Netflix, Amazon Prime Video, Disney+/Hulu, Apple TV+, and a live sports/video stream. That gives us 45 documented workflows across the May–July 2026 cycle.

We record the stage actually reached. Stable playback is stronger evidence than a homepage loading, and a login or catalog view is not silently upgraded to a playback pass. The current matrix contains 38 stable-playback results, three stable results that required specialized streaming servers, one additional playback-confirmed result, one partial login/catalog result where playback was blocked, and two failures before playback.

Streaming is volatile. A result can change with the service, catalog, account region, app, browser, server, protocol, or time. The result tells you what happened in our documented workflow, not what every subscriber will see forever.

Platform boundaries

How we handle apps, protocols, and advanced features

Windows 10 is the deepest common hands-on platform in the current nine-provider cycle. We use relevant Android or browser workflows when they add evidence, but we do not turn a Windows result into a macOS, iOS, Linux, TV, or router claim. For an untested platform, we rely on current official documentation and label the statement accordingly.

The same rule applies to features. A native WireGuard result is not treated as identical to a workflow that requires the official WireGuard app and an imported configuration. App-based split tunneling is not equated with a command-line method we did not run. A dedicated-IP menu being visible does not mean we purchased the add-on.

Port forwarding being documented does not mean we successfully opened an inbound port unless the review says we did. For the feature-level test method and the differences across providers, see our VPN port forwarding guide.

This product-specific treatment is deliberate. Standardization matters for comparison, but forcing every VPN into the same feature labels can be less accurate than preserving how the feature actually works.

Buying-risk workflow

How we check support, cancellation, and refunds

Support is most useful to our methodology when it resolves a concrete uncertainty: refund eligibility, renewal treatment, a platform limitation, a missing feature, or a setup problem that the public documentation does not settle. We record what the agent clarified in that interaction. We do not call a provider’s support universally excellent or terrible from one conversation.

Cancellation and refund are also kept separate. Turning off auto-renewal can stop a future charge without returning the current payment. A money-back policy can have limits based on timing, renewal status, purchase channel, payment method, add-ons, or app-store rules. Our reviews document the path we actually used rather than treating the guarantee headline as the whole story.

The final confirmation record shows that all nine payments were returned in full. Six arrived on the request date, two on the next calendar date, and Turbo VPN arrived seven calendar days later. VPN.ac did not provide a written approval before the account became inaccessible, but the full PayPal payment returned on the request date. We still keep request, approval or processing, access ending, and actual receipt separate because those events answer different questions. See the dated rows in our VPN trial and money-back guarantee comparison.

Claims versus evidence

How we review privacy and trust claims

Privacy claims need a different evidence standard from an app setting. We separate what the provider says from what a policy states, what an independent audit reports, what open-source code makes inspectable, what a support agent clarified, and what our own consumer checks can directly observe.

We therefore avoid turning a clean browser leak check into “this VPN never leaks,” or a no-logs page into “we independently proved no logs exist.” Strong privacy evidence is useful; its boundary is part of the finding.

Current evidence by provider

ReviewsAlly VPN testing scope matrix — 2026

This table is about evidence scope, not ranking. Providers are listed alphabetically. “Speed records” counts every consolidated row for that provider, including baseline, VPN-route, and protocol-comparison records. Each provider has five streaming workflows in the final matrix.

The downloadable CSV adds check-level fields for DNS, WebRTC, kill switch, split tunneling, support contact, and refund-request status without exposing private research data.

Download the ReviewsAlly VPN Testing Scope Matrix — 2026 (CSV)

Evidence hygiene

How we handle screenshots, raw data, and missing fields

Public evidence should help a reader verify the method without exposing the reviewer. We publish screenshots that are safe and relevant, such as VPN-on Speedtest results, app settings, and sanitized browser-check outputs. We keep real-IP baselines, private billing information, account identifiers, email addresses, payment details, streaming profiles, credentials, private support transcripts, and internal source filenames out of public assets.

Raw research files and the full internal speed dataset also stay private because they contain local-environment details and working notes that are unnecessary for readers. The public CSV is a scope matrix, not a dump of the internal research database. When we later publish a dedicated VPN speed-test dataset, it should receive its own sanitization and methodology review.

Missing data stay missing. We do not infer a jitter value from a neighboring run, copy a protocol label across rows, or reconstruct a timestamp because it looks obvious. If a field is important to a future comparison, the right fix is a new documented test or an explicit limitation.

Method evolution and limits

What our VPN tests can and cannot prove

Our VPN testing framework became more structured as we completed the first nine paid reviews. Earlier sessions may contain fewer repeated routes or fewer captured secondary metrics than later sessions, but every published number comes from a real recorded test. We keep those differences visible instead of filling gaps after the fact, and we consider evidence completeness when it materially affects interpretation or a close comparison.

Our goal is careful, reproducible consumer evidence, not to imitate a carrier-grade laboratory. Each provider’s speed-test session took hours, and the first completed cycle produced 268 speed records across nine paid services. More devices, networks, countries, and recurring retests would widen the evidence; they do not change the integrity of the tests already completed.

From evidence to recommendation

How test evidence informs our VPN rankings

Our overall VPN ranking is not the speed table with a different heading. Speed is measured with the formula above, while the editorial ranking also considers buyer fit, streaming behavior, app reliability, privacy/security evidence, usability, platform coverage, pricing and renewal clarity, refund experience, and the severity of any documented caveat.

We do not convert those judgments into invented star ratings or a fake universal score. A fast VPN can rank lower if a material leak, app failure, unresolved refund, or narrow use case outweighs its performance advantage. Conversely, a provider does not become “best” merely because it has the longest feature list.

The ranking criteria, top-three emphasis, commercial relationship note, and current provider order live in Our VPN Methodology on the Best Picks page. Keeping the ranking logic there avoids turning this evidence page into a second Best VPN list.

Maintenance policy

How we update the methodology and correct evidence

We review this methodology when the testing process materially changes, when a new test type becomes part of the shared workflow, or when the evidence model needs a clearer boundary. Provider-specific facts such as pricing, renewal terms, app capabilities, streaming access, server claims, and refund policies are updated on their own schedules because they can change faster than the methodology itself.

When a new test supersedes an earlier result, the public page should identify the newer evidence rather than preserve a known contradiction for the sake of history. When the evidence is unresolved, we say so. Corrections should change the affected claim, table, FAQ, and related comparison language together so readers do not encounter two incompatible versions of the same finding.

See the evidence in context

Read our current VPN findings

The methodology tells you how the evidence is collected. The Best VPN Services of 2026 page shows how we compare the current providers, while each individual review keeps the plan, platform, screenshots, measured results, support notes, and caveats for that service.

Sources and tools

Tools and evidence sources used in this methodology

Research cycle: May–July 2026. Method reviewed: August 2026.

Common questions

VPN testing methodology FAQ