Test a Host
Or start from one of these:
Measuring...
Nothing is uploaded. The browser makes the requests and the report is built in this page.
Why a Chatbot Cannot Tell You Your Ping
Ask a chatbot what your ping is and it will give you a number that means nothing. Latency is not a property of you, your provider, or a region. It is a property of one specific path between one specific router and one specific server, and that path is different in every direction and changes whenever anything in the middle reroutes. A model has no way to look any of that up, so whatever it tells you is recalled text, not a measurement.
This is the second reason chatbot answers mislead here. Averages hide the two things players actually feel. A connection sitting at 45ms with 3ms of jitter feels instant, and a connection sitting at 25ms with 90ms of jitter feels like it is underwater. Same average, completely different experience. You need the spread, not the midpoint, and no text model can produce either without running the requests.
The third reason is the one that wastes the most time. A slow server and a slow connection produce the same symptom, and they need opposite fixes. If your link is the problem, nothing you do to the game will help. If the route to one host is the problem, the fix is a different host, a different region, or a different provider, and your router is irrelevant. You can only tell those apart by measuring several targets at once, because the answer is a pattern across targets rather than a number on one of them.
What You Get
- The whole distribution, not one number. Minimum, average, median, 95th percentile, maximum, standard deviation, peak-to-peak and the RFC 3550 jitter figure for every host, so an outlier or a quietly congested line is visible instead of being averaged away.
- Cold cost measured separately. The first request to a host is kept as its own number, so the DNS, TCP and TLS handshake cost is visible rather than blended into your latency.
- Loss counted as requests, not ICMP. Congested routers routinely drop ICMP while passing real traffic, so counting requests that never came back tells you about the loss your applications actually experience.
- Graded per activity. Competitive shooters, casual shooters and MOBAs, MMORPGs, voice chat, video calls, remote desktop, browsing and plain API calls each get their own verdict, because a single label would hide the difference between a 45ms line and a 150ms one.
- Side-by-side host comparison. Uniformly slow across every target points at your connection. One outlier against a field of normal targets points at the route to that host. Those need opposite fixes.
- A copyable report. One button puts the whole result into a text block for a forum post, a support ticket or a Discord channel.
How the Measurement Actually Works
A browser cannot send ICMP echo packets. No page you load can, and any tool that claims to is either running a native app or is quietly measuring something else. What this tool measures instead is the round trip of a real HTTPS request from your browser to the target host, timed with the same performance clock the browser uses for navigation. That is a genuine network round trip through your provider, across the internet and back into the target's server, and it is the number your applications feel.
The difference from a terminal ping matters more than it looks. ICMP is the cheapest thing a router can carry, so congested networks frequently deprioritise it. A path can show 20 percent ICMP loss while HTTPS runs perfectly, which is why a traceroute full of red hops is frequently just a router telling you to go away. Request loss, which is what this tool counts, is the loss that breaks video calls and game sessions. If the two disagree, believe the request measurement.
Requests are issued from your browser to the target with the response body ignored, so the target never sees the contents of anything and the measurement does not depend on which page you happen to have open. Samples run a quarter of a second apart so that they sit inside one congestion window instead of averaging out over minutes. Anything that does not answer within five seconds is recorded as a lost sample rather than as an extremely slow one, because a request that takes five seconds is functionally the same as a request that never arrived.
What Each Number Means
The minimum is the best the path ever managed and it is a useful floor for planning, because it is roughly what you would get on an unloaded network. The median is the typical case and is a better read on day-to-day feel than the mean, since a single very slow sample drags a mean up hard. The 95th percentile is the number that predicts whether you will get a stutter: if your average is fine and your 95th percentile is not, the problem is spikes, and spikes are congestion.
Jitter here follows the definition in RFC 3550, the mean absolute difference between consecutive round trips, which is the same figure VoIP and game networking use. Under about 10ms it is not something you will consciously notice. Between 10 and 30ms it starts to show up in voice. Above 30ms, audio buffers and prediction start fighting each other and the call stutters even while the average latency looks healthy. Standard deviation and peak-to-peak are shown next to it so that an unstable line with a low average cannot hide.
Loss is the share of samples where the target never answered. One lost request in twenty is a line you will hear in a call. Five percent or more is a physical or Wi-Fi problem rather than a routing one, and no amount of choosing a nearer server will fix it. Because these are request failures rather than dropped ICMP packets, a reading of zero here is a stronger statement than a clean ping.
How to Read Your Result
Start with the comparison table, not the grade. If your own server, Google and GitHub all report roughly the same high figure, the bottleneck is between you and the internet, and the candidates are your Wi-Fi, your router under load, a saturated uplink, or bufferbloat on a router that queues far more than the line can drain. Wired, reboot the router, and re-run. If wired and unchanged, the test again later, because a consistent 60ms to every host usually means the provider is routing you the long way.
If the field is mostly normal and one target is far worse, you have a path problem to that specific host and your local setup is not the culprit. That is a common outcome with game servers: the publisher routes your region to a data centre that is genuinely far away, and no setting on your side changes it. The fix is a nearer region, another host in the same service, or a different provider if they offer one, and this tool gives you the evidence to say so before you spend an evening on the wrong setting.
If latency looks fine but jitter or the 95th percentile is bad, the line is congested rather than slow. Bufferbloat is the usual culprit and it has an unusual signature: latency is excellent while nothing else is happening, then spikes badly the moment someone starts an upload. Check whether latency rises while a large file is uploading, and if it does, enable smart queue management or set a per-device rate limit on the router.
If the cold number is far above the warm average, the server or the resolver is slow to complete a handshake. That costs you a visible delay on first contact and then nothing, so it rarely matters for a game server you stay connected to but it explains a lot of why a website feels sluggish on a first visit and instant on every visit after.
What This Tool Will Not Tell You
It will not show you the path. There is no traceroute here, because hop-by-hop tracing needs raw sockets that a web page cannot open, and any site offering it is using a server that traces from its own location rather than from yours. When you need to know which hop is degrading, run a real traceroute from your own machine. What this tool does give you is the one measurement a server-side traceroute cannot substitute for: what the round trip looks like from where you are sitting.
It will not tell you your bandwidth. A line can carry plenty of data and still respond badly, and a line can have the lowest possible latency and still stall on a large download. Latency and throughput are different properties measured by different methods, and the speed test on this site covers the second one. If you are wondering whether a download will finish quickly, that is the other tool. If you are wondering why a game moves in bursts or a call drops words, it is this one.
It will not tell you whether the target itself is slow to answer. A request is timed until the first response headers arrive, so a server that answers instantly and then takes four seconds to produce a page will still look fast here. That is a fair trade, because connection setup is what causes lag, but it does mean a slow site can pass this test and still feel slow to use.
Frequently Asked Questions
Why is your ping different from the ping command in my terminal?
Two reasons, and both are expected. First, this measures HTTPS request round trips while the terminal sends ICMP echo packets, and congested networks routinely deprioritise ICMP while treating HTTPS normally, so the terminal can show loss that does not exist for real traffic. Second, the terminal pings from your machine while this runs in a browser tab, so it also includes the path through your provider in the same way, but the two will differ by a few milliseconds just from timing and DNS behaviour. Treat the browser number as what your applications experience and the terminal number as what the network path is doing at the IP layer.
What is a good ping for gaming?
Under 20ms is excellent and you will not think about it. Between 20 and 50ms is good and fine for almost anything, including competitive shooters at their real tick rate. Between 50 and 100ms is playable but you will notice it in fast shooters and it is where hit registration complaints usually come from. Above 100ms stops feeling responsive regardless of the game. Those numbers assume jitter under 10ms and zero loss. A stable 80ms beats an unstable 40ms every time, and this tool shows both so you can tell which one you have.
My ping test shows packet loss but my game is fine. What gives?
Almost certainly ICMP deprioritisation rather than a real fault. Routers treat ICMP as the lowest priority traffic they carry, and a busy link will start dropping it while still passing HTTPS and game traffic intact. That is why this tool counts requests that never came back rather than packets that were never answered, and why a reading of zero here is worth more than a clean ping in a terminal. If you are seeing real loss in games and also see it here, then you have a genuine problem and the comparison against your other targets is where the cause shows up.
Is jitter or loss worse than high ping?
For anything real-time, jitter and loss are worse. Ping is a constant delay, and applications can buffer a constant delay. Jitter is a delay that keeps changing, and buffers have to constantly refill and drain, which is what produces stutter and robotic audio. Loss is worse than both in most cases because most real-time protocols treat a dropped packet as a gap that must be concealed, and repeated concealment is audible and visible. This tool grades latency, jitter and loss separately for exactly this reason, because a single combined label would hide it.
Why is the first measurement higher than the rest?
Because the first request to a host has to do work that later ones do not: resolve the name, open a TCP connection, negotiate TLS and, on some hosts, populate a CDN edge from origin. Each of those is a real network round trip, sometimes several, and none of them happen again on a warm connection. This tool reports that first sample separately as the cold number so you can see the handshake cost instead of having it averaged into your latency. If the gap is large, that is a real and separate problem for anything that opens a new connection, such as browsing to a site you have not visited before.
Can I test a game server, an IP address or a URL?
Yes, all three. Type a hostname such as a game server, an IP address such as 1.1.1.1, or a full URL and the path gets dropped so you always test the host. Enter several separated by commas or spaces and they are sampled in turn, which is what makes the comparison useful. Keep in mind that you can only test hosts that serve HTTPS, because a browser blocks requests to plain HTTP from a secure page, and you can only test the host and not a specific port or an interior service behind a proxy.
Why does one of my targets time out?
Four causes account for nearly all of it. The host does not answer HTTPS requests on that address, which is normal for bare IP addresses that are not set up as web servers. The host blocks requests that do not look like a browser. Your network or the host's network drops those particular requests. Or the host is genuinely down or unroutable from where you are. Test a known target alongside it. If the known one is fine, the problem is that host or the path to it, not your connection, and the diagnosis below will say so.
Is my IP address or the host I type stored or logged anywhere?
No. The measurements are made by your browser straight to the target, so the target sees a normal HTTPS request from your address the same as any page load would. Nothing is sent to us, because there is no server component here at all. The report is assembled in the page, and it disappears when you close the tab. Copy it out first if you want to keep it.
Comments & Ratings