Ping Test

Measures the round-trip time between your browser and a server, repeatedly, so you can see not just how fast your connection is but how steady it is. Jitter and dropped requests are what ruin video calls and games — average latency on its own hides both.

Timing an HTTPS request to our server in Frankfurt. A browser cannot send ICMP, so this is a web round trip rather than a true ping — see below for what that changes.

—

Best—ms

Average—ms

Worst—ms

Jitter—ms

Failed—%

Key takeaway: the average is the least interesting number here. A connection averaging 40 ms with 30 ms of jitter feels worse on a call than one averaging 80 ms that never wavers, because the software has to buffer for the worst case, not the typical one.

Why this is not a real ping

The ping command sends an ICMP echo request — a tiny packet whose only job is to come back. Browsers cannot send ICMP at all, for good reason: a web page that could emit arbitrary packets would be a port scanner. So every browser-based ping test, this one included, is timing something else: a complete HTTPS request and response.

That measurement includes real work ICMP never does — the server has to accept the connection, hand the request to a web server and answer it. We keep that overhead as small as it can be (the endpoint returns an empty 204 No Content and touches nothing else), and the first request of each run is discarded so the DNS lookup and TLS handshake are not counted. What remains is a few milliseconds above true network latency, consistently.

Which means: treat these numbers as comparable to each other, not to the output of ping. Comparing your result now to your result an hour ago, or on Wi-Fi versus cable, is exactly what this is for. Comparing it against a friend’s ICMP ping figure is not.

Run a real ICMP ping instead

If you want the genuine article, it is one command. Windows sends four by default; the others run until you stop them with Ctrl+C:

Windows ping -n 20 1.1.1.1 macOS/Linux ping -c 20 1.1.1.1

Read the summary line at the end rather than the individual replies: it gives you minimum, average, maximum and packet loss in one place. To find where the latency appears along the route, traceroute shows you each hop.

How to read the five numbers

Number	What it tells you
Best	The floor — the physical distance and routing, when nothing is in the way. It barely changes unless your route changes.
Average	The typical case. Useful for comparing two connections, nearly useless on its own for diagnosing a problem.
Worst	The one that hurts. A single 900 ms spike is what a call hears as a stutter.
Jitter	How much consecutive results differ from each other. The most diagnostic number on the page.
Failed	Requests that never completed. Over a short run this is a rough proxy for packet loss, not a precise measurement of it.

As rough rules of thumb for real-time use: under 50 ms with low jitter is comfortable for anything, including competitive games. Up to about 100 ms is fine for video calls and most games. Past roughly 150 ms conversation starts to feel like talking over a radio, with people interrupting each other. Browsing tolerates far more than that — pages load in parallel, so latency matters less than it does for live audio.

What jitter actually breaks

Video calls and games need packets at a steady rate. When arrival times scatter, the receiving software has to hold a buffer big enough for the late ones, which adds delay for everybody, or play what it has and produce the gap you hear as a robotic stutter. That is why a connection with 25 ms average and 40 ms jitter sounds worse than a steady 90 ms line. Wi-Fi interference, an overloaded router and bufferbloat during large uploads are the usual causes — and all three show up here as spikes in the bar chart while the best-case stays flat.

Latency is not speed

These are two different properties and improving one does not improve the other. Latency is how long a single packet takes to make the trip; bandwidth is how much data fits through per second. Upgrading from 100 Mbps to 1 Gbps will not reduce your ping, because the packet still travels the same distance through the same routers — it is the difference between the width of a pipe and the length of it. If your pages feel slow but this test looks healthy, bandwidth or DNS is the more likely culprit: try the speed test and the DNS checker.

When the result looks bad

Work outwards from your own equipment, because that is where most of it lives. Test on Ethernet if you can — if cable is steady and Wi-Fi is not, the problem is in your home, not at your provider. Run the test again while a large upload is in progress; if latency collapses only then, that is bufferbloat in your router rather than a fault on the line. Check whether other devices are saturating the connection. Only after all that is it worth working through the wider diagnosis, or looking at whether your provider is throttling.

Two things are outside your control entirely: distance, and carrier-grade NAT, where your provider routes you through shared equipment that adds a hop before you reach the internet at all.

A VPN always adds latency — the question is how much

Your traffic takes a detour through the VPN server, so ping goes up by roughly the round trip to that server. Picking one physically near you keeps the penalty small; picking one on another continent will double or triple it. Run this test with the VPN off, then on, and compare — that difference is the real cost, and it is the only number that matters when choosing a server.

PureVPN IPVanish

Affiliate links. We do not rank by commission — here is how to compare providers yourself.

What this test cannot tell you

It cannot tell you your latency to somewhere else. Ping is a property of a route, not of your connection: fast to Frankfurt says nothing about a game server in Brazil. It cannot separate your Wi-Fi from your provider from the wider internet — for that you need traceroute, which times each hop individually. And it cannot prove packet loss. A browser retries and buffers beneath you, so genuine loss is best measured with a long ICMP run using the commands above.

Frequently asked questions

Why is my browser ping higher than the ping in my game?

Different destination, different protocol, and extra work at both ends. Your game talks UDP to a server chosen for being near you; this talks HTTPS to a server in Frankfurt and waits for a web server to answer. The gap between the two numbers is normal and not a sign of a problem.

What is a good ping?

Whatever is low enough for what you are doing, and steady. Under 50 ms suits everything; under 100 ms is comfortable for calls and most games; beyond 150 ms real-time conversation gets awkward. Consistency counts for more than the figure — see the jitter section above.

Can I lower my ping?

Some of it. Use Ethernet instead of Wi-Fi, move off a congested channel, enable Smart Queue Management on the router if it has it, and stop background uploads. What you cannot change is distance or your provider’s routing — no setting makes a server 2,000 km away answer faster.

Does a higher speed plan reduce ping?

Almost never. Faster plans move more data per second; they do not shorten the journey. The exception is a connection so saturated that packets queue behind other traffic, where extra headroom does help — and a change of technology, such as moving off satellite or older DSL, changes latency because the underlying physics changes.

Why did one request fail?

An occasional failure over a short run is usually nothing — a dropped connection, a retry, a moment of Wi-Fi interference. Repeatable failures are worth investigating, and if you test a custom hostname, remember a failure there may simply mean that host has no web server on HTTPS, not that it is unreachable.