How to Test Your VPN Speed in 2026 (And What the Numbers Actually Mean)

A useful VPN speed test answers a practical question: can this connection handle what you actually do? Download speed matters for large files, upload speed matters for sending them, and response time matters for conversations and games. This guide shows how to measure all three, interpret published benchmarks, and isolate a slowdown without chasing a single impressive screenshot.

Reference Speeds from Third-Party Tests (Oct 2026)

Compiled on October 31, 2026 from Security.org’s published VPN speed tests, updated September 10, 2026. The publisher describes a wired 100 Mbps fiber connection, OpenVPN, Australian exit servers, and ten runs per service. October is our compilation date, not a claim that the measurements were collected that month. These are averages from that setup, not maximum capacities or predictions for your line.

Security.org published averages: 100 Mbps fiber, OpenVPN, Australian servers

VPN	Download (Mbps)	Upload (Mbps)	Ping (ms)
NordVPN	89.11	90.72	78.3
ExpressVPN	87.48	71.65	125.8
Surfshark	87.25	47.32	135.8
Proton VPN	86.07	90.66	78
Private Internet Access	90.48	14.86	86.7

These figures are compiled from published third-party tests. FIVE PICKED has not independently verified them.

Read this as one reference point. The capped line constrains throughput, while the distant route affects ping. A modern-protocol test on gigabit fiber answers a different question. Do not combine its headline result with this table’s latency to create a comparison that no publisher actually measured.

What the numbers actually mean

Download speed is the rate at which data reaches your device. Mbps means megabits per second; it is different from the megabytes used for file sizes. A faster download result can shorten transfers, but an already adequate connection may show little visible improvement when reading ordinary pages.

Upload speed describes traffic leaving your device. It matters when you send recordings, synchronize backups, share a screen, or broadcast video. Check it independently: a good download result does not establish good upload performance. A saturated upstream connection can also make other activities feel unresponsive.

Ping measures round-trip response time in milliseconds. Lower is generally better for interactive tasks, but compare the same destination. Idle ping and latency measured during a transfer are different observations. Variability between readings matters too: a stable route can feel better than one alternating between quick responses and long pauses.

Step 1: establish a clean baseline

Use the computer and connection you normally rely on. Ethernet is preferable when isolating VPN performance because it removes many wireless variables. If Wi-Fi is your everyday connection, test it afterward as a separate scenario. Keep the device in the same place and record whether other people are using the network.

Pause backups, downloads, updates, and other bandwidth-heavy tasks. Disconnect the VPN, open Ookla Speedtest, and record three runs. Save download, upload, and ping rather than just the best result. Note the time, device, operating system, and measurement endpoint. The baseline is your observed connection, not the maximum speed advertised by your internet plan.

Step 2: change one variable at a time

Connect to a nearby VPN location and record the actual city and protocol selected. Keep the Speedtest endpoint fixed for the controlled comparison. The VPN exit server carries your encrypted traffic; the measurement endpoint receives the test traffic. Changing both together makes the cause of a difference harder to identify.

Run five measurements, leaving a short pause between them. Disconnect and check the baseline again. If the underlying connection changed substantially, repeat the session before blaming the VPN. Compare the middle result, or median, and keep the lowest and highest readings so a single peak cannot conceal an erratic connection.

Repeat for a location relevant to you, such as a European or United States server. Keep nearby and long-distance results separate. If comparing providers, rotate their testing order in another session. Record failed connections as well as successful runs; deleting failures would make an unreliable configuration look better than it behaved.

Step 3: calculate retention and added delay

Download retention equals VPN download speed divided by the matching disconnected baseline, multiplied by one hundred. Upload retention uses the same calculation for upstream traffic. Calculate each from measurements collected close together. This makes the comparison more informative than comparing absolute Mbps figures from unrelated internet connections.

Added latency equals connected ping minus disconnected ping to the same endpoint. Use the absolute increase alongside the final connected value. A percentage increase can look dramatic when the starting ping is tiny, while telling you little about whether a call or game remains comfortable. Keep loaded latency separate when the tool reports it.

Turn measurements into a useful decision

For video calls, repeat your test while making a normal call and note audio interruptions, frozen video, and screen-sharing behavior. For large transfers, time a file you genuinely need to move. For games, check the game’s own server latency because its destination may differ from your speed-test endpoint.

For streaming, observe playback on the actual service and device. Record startup time, selected quality, buffering, and any playback error over a consistent viewing window. Bandwidth alone cannot establish service compatibility. Repeat at your usual evening viewing time before deciding the connection is consistently good enough.

Choose the setup that meets your workload repeatedly, including busy periods. A small difference between clean speed-test results may matter less than a connection that stalls or reconnects during work. Keep privacy requirements in the decision as well: a faster configuration is not useful if it bypasses protection you intended to keep.

A practical troubleshooting sequence

First repeat the disconnected baseline. If that is slow too, investigate your local connection before changing VPN settings. Check Ethernet or wireless conditions, background activity, and whether another device is filling the connection. Repeating this check avoids spending time tuning an application that is not causing the bottleneck.

Next reconnect to another nearby server and repeat the same endpoint test. Then try another supported protocol as a separate configuration, recording its name. Change one setting at a time and retain the earlier results. Do not disable encryption, the firewall, or essential protections simply to improve a benchmark score.

Finally reproduce the problem in the application that feels slow. A speed test and a video meeting use different destinations and traffic patterns. If the problem persists, send support your device version, protocol, approximate server location, timestamps, and repeatable symptoms. Remove account secrets and public IP addresses from anything shared publicly.

Compare the right versions of a service

Record the account tier when a provider offers different access options. A free account and a paid account may expose different locations or server choices, so their results should have separate labels. Likewise, a desktop application result should not be presented as a measurement of a browser extension, router installation, or phone.

When reading another publisher’s benchmark, look for the connection ceiling, operating system, protocol, destination, aggregation method, and publication date. If a detail is absent, keep that uncertainty attached to the result. Avoid converting a limited benchmark into a universal ranking. The useful question is whether its conditions resemble the conditions you need, and whether your own repeated observations support the same practical decision.

Keep a short, reusable test log

One row per run is enough: timestamp and time zone, network type, VPN location, protocol, test endpoint, download, upload, ping, and a short observation. Save result links or screenshots when available. Group runs by session so later comparisons do not accidentally mix a quiet morning with a congested evening.

Retest after changing your router, device, VPN application, or regular location. Keep the previous log rather than overwriting it; a before-and-after comparison helps distinguish a persistent limitation from a temporary bad route. Stop testing once repeated measurements answer your actual decision. More screenshots do not automatically produce a more useful conclusion.

Choose your next step

Start with our VPN and security shortlist, then use the VPN selection guide to define your requirements. The VPN matching quiz organizes priorities, while our free-plan and trial comparison explains access options. Use published benchmarks to shortlist candidates and your own repeatable measurements to make the final choice.

Frequently asked questions

How do I test my VPN speed fairly?

Measure a disconnected baseline, then repeat connected tests on the same device and endpoint. Record the protocol and server location, compare repeated runs, and recheck the baseline during the session.

Why can downloads be fast while calls feel slow?

Download throughput and responsiveness measure different things. Check upload performance, latency under load, and the call itself before deciding that a high download result proves the connection is suitable.

Are the reference figures October 2026 measurements?

October 2026 is the compilation date. The linked Security.org article was updated September 10, 2026; its reported test setup and averages are identified above.

Does a successful speed test guarantee smooth streaming?

No. Test playback on the actual service and device, observing startup, quality, interruptions, and errors. Repeat during your normal viewing hours to assess consistency.