VPN Speed Comparison Tool
Test your internet speed before and after enabling your VPN. See the exact speed loss, ping increase, and overhead — all measured live in your browser. Pair this with the ping test or jitter test if you want to isolate latency and stability specifically.
Speed dashboard
Ready to test
Without VPN
--
Mbps download
--
Upload Mbps
--
Ping ms
--
Jitter ms
VS
With VPN
--
Mbps download
--
Upload Mbps
--
Ping ms
--
Jitter ms
Test history
Without VPN
With VPN
What affects VPN speed
Server distance
The farther the VPN server from your location, the more your packets travel — adding measurable latency on every single request you make.
High impact
Encryption protocol
WireGuard loses roughly 5–10% of your base speed. OpenVPN loses 20–30%. Older protocols like PPTP are faster but dangerously insecure. Protocol choice matters enormously.
High impact
Server load
An overloaded VPN server slows everyone connected to it. Peak hours (6–10 pm local time) often show 20–40% more overhead than the same test run during off-peak hours.
Medium impact
Your device CPU
VPN encryption and decryption is CPU-bound processing. Older smartphones or budget home routers can cap your VPN throughput well below your ISP's maximum speed.
Lower impact
Industry speed benchmarks — top VPNs tested
| VPN | Avg download | Overhead | Protocol | Rating |
|---|---|---|---|---|
| NordVPN | -9% | NordLynx (WG) | ||
| Mullvad | -7% | WireGuard | ||
| Surfshark | -12% | WireGuard | ||
| ExpressVPN | -16% | Lightway | ||
| ProtonVPN | -24% | WireGuard | ||
| Free VPN (avg) | -62% | OpenVPN |
How to maximise your VPN speed
1
Switch to WireGuard protocol
WireGuard uses modern cryptography that is significantly faster than OpenVPN or IKEv2. Enable it in your VPN app settings — every major paid VPN supports it in 2024.
Up to +30% speed
2
Connect to the nearest server
Every 1000 km of server distance adds roughly 10–15 ms of ping. Always pick the closest city to your location, not a default "recommended" server in another country.
Up to +25% speed
3
Test at off-peak hours
VPN server load drops dramatically between midnight and 8 am in the server's local timezone. Schedule bandwidth-heavy tasks like downloads and backups during these hours.
Up to +20% speed
4
Use split tunnelling
Route only privacy-sensitive traffic through the VPN tunnel. Streaming, gaming, and cloud backups can bypass it entirely — which dramatically improves effective speed.
Up to +40% effective
5
Upgrade from a free VPN
Free VPNs deliberately throttle speeds and run severely overcrowded servers to control costs. A premium VPN typically delivers 5–10 times more bandwidth for actual use.
Biggest single upgrade
6
Restart your router first
ISP-assigned routing tables and IP leases change over time. A quick router restart refreshes your connection path and often reduces baseline latency before you even connect a VPN.
Quick 2-minute fix
Understanding your results
Loss under 20% — excellent VPN
A speed loss below 20% means your VPN is performing at the top of the industry. WireGuard-based VPNs on nearby servers consistently land here. Suitable for 4K streaming, gaming, and video calls with no noticeable impact.
20–40% loss — acceptable overhead
Normal performance for OpenVPN protocol or servers located in a different region. HD streaming and general browsing remain comfortable. Competitive online gaming may be slightly affected. Consider switching to WireGuard.
Over 40% loss — investigate your setup
Heavy overhead like this suggests an overloaded server, the wrong protocol, or an underpowered VPN provider. Switch to a different server, try WireGuard, or consider upgrading your VPN subscription to a faster provider.
Ping over 100 ms — impacts real-time apps
Latency above 100 ms causes noticeable lag in video calls, voice chat, and online gaming. Download speed is less important than ping for these use cases. Always choose the geographically closest VPN server available.
Why a single before/after percentage isn't the whole story
These are the technical realities that affect what a VPN speed comparison can actually tell you — the nuances that separate a genuinely useful test result from a number taken at face value.
Multi-hop VPN overhead compounds — it doesn't add
Chaining two VPN servers ("double VPN" or multi-hop) doesn't just add their overhead percentages together. If one hop costs 20% and a second costs 20%, the combined loss is closer to 36%, not 40% — because the second hop's overhead applies to the already-reduced throughput coming out of the first, not your original baseline speed. Multiplicative loss compounds faster than most users expect as more hops are added.
Your ISP may be throttling VPN traffic specifically, not just congested
Some ISPs use deep packet inspection to recognize VPN protocol signatures — OpenVPN's default UDP port and handshake pattern are particularly easy to fingerprint — and apply targeted throttling independent of general network congestion. If your speed loss is dramatically worse than your VPN provider's own benchmarks suggest it should be, try an obfuscated or "stealth" protocol mode if your provider offers one; a large gap between expected and actual overhead is a real signal worth investigating, not just accepting.
Long-distance, high-bandwidth connections lose disproportionately more to VPN overhead
The relationship between latency and achievable throughput (the bandwidth-delay product) means a VPN's encryption and handshake overhead has a bigger relative impact on high-latency, long-distance connections than on short, local ones. This is part of why a VPN server on another continent doesn't just add ping — it can cost you proportionally more of your total bandwidth than the same VPN would on a nearby server, beyond what the extra distance alone explains.
A "before" and "after" test aren't testing the same conditions unless you control for time
Running the without-VPN test, then taking a few minutes to enable your VPN, then running the with-VPN test means the two tests happened at different moments — and network conditions genuinely change minute to minute from ISP congestion, Wi-Fi interference, or other devices on your network. A large gap can be entirely accurate, or it can be your baseline connection having a bad moment unrelated to the VPN. Running each test 2–3 times and comparing the median result is more reliable than trusting a single before/after pair.
A browser-based speed test measures something slightly different from a native app
This tool, like most in-browser speed tests, measures throughput using parallel HTTPS fetches limited by your browser's maximum simultaneous connections per host. Native download managers and dedicated speed-test apps can sometimes achieve marginally higher throughput by using more aggressive parallel connections. The relative comparison between your with-VPN and without-VPN results stays valid and meaningful — just don't expect either number to be the absolute ceiling of what your connection can theoretically do.
Frequently asked questions
“Why did my VPN speed test show a big loss even though I have a fast connection?”
Speed loss is usually more about protocol and server distance than your base connection speed. OpenVPN typically costs 20–30% of your speed; WireGuard-based protocols cost closer to 5–10%. A distant server compounds this further. Check which protocol your VPN app is using — switching to WireGuard is usually the single biggest improvement available.
“Is a 20% speed loss "bad"?”
No — under 20% loss is considered excellent by industry standards and is typical of well-optimized WireGuard-based VPNs on a reasonably close server. It becomes worth investigating above roughly 40%, which usually points to server overload, an outdated protocol, or ISP throttling of VPN traffic specifically.
“Why does a double VPN (multi-hop) slow things down so much more than a single VPN?”
Overhead from each hop compounds rather than adding together — a second 20%-overhead hop applies to the already-reduced speed coming out of the first hop, not your original baseline. Two hops at 20% each produce roughly 36% total loss, not 40%. This effect gets more pronounced the more hops you chain.
“Can my ISP make my VPN look slower than it actually is?”
Yes. Some ISPs use deep packet inspection to detect and specifically throttle recognized VPN traffic patterns, independent of general network congestion. If your measured overhead is dramatically worse than your provider's published benchmarks, try an obfuscated/stealth protocol mode if your VPN app offers one, and compare results.
“Does testing "before" and "after" VPN back-to-back give an accurate comparison?”
Close, but not perfectly controlled — a few minutes pass between the two tests while you toggle your VPN, and real network conditions shift minute to minute regardless of the VPN. For a more reliable read, run each test 2–3 times and compare the median rather than trusting a single before/after pair.
“Does this tool measure my absolute maximum internet speed?”
It measures real, meaningful throughput using parallel HTTPS requests from your browser — the same approach used by most browser-based speed tests — but browser connection limits mean it may read marginally below what a native download manager could theoretically achieve. The relative comparison between your with-VPN and without-VPN results stays accurate either way.
“Why is my upload speed loss different from my download speed loss?”
Many ISPs provision asymmetric connections with far less upload bandwidth than download to begin with, so the same absolute overhead from VPN encryption represents a larger percentage of your smaller upload capacity. It's normal for upload loss percentage to look worse than download loss on the same test.
“Should I test on a wired connection or Wi-Fi?”
Wired Ethernet is more reliable for isolating VPN overhead specifically, since Wi-Fi introduces its own variability from interference and signal strength that can get conflated with VPN performance. If you only have Wi-Fi available, run the test a few times and expect somewhat more variation between runs — see the jitter test if you want to check connection stability specifically.