DeviceBenchFree browser ping test
Ping test that shows every probe, not just the best one
Twenty, fifty or a hundred and twenty timed requests leave this tab for the nearest edge node holding this site, and each round trip is drawn as a point the moment it lands. You get best, median and worst instead of one flattering figure, the count that came back, and the handshake the first probe paid before the rest could reuse its connection. Because a web page cannot open a raw socket, this is an HTTPS round trip rather than an ICMP echo, and it reads a few milliseconds above what the ping command prints.
- 100% free
- No signup
- Up to 120 probes
- Best, median and worst
- Handshake broken out
Each probe asks this domain for a three-byte file under a URL it has never seen, so nothing can answer from a cache. 50 of them takes about 10 seconds.
Run the probes and this fills with the setup cost your browser paid once, then reused.
Every probe after the first one reuses that connection, which is why the timeline flattens after the left edge.
- Request to first byte
- —
- Whole fetch, wall clock
- —
- Difference
- —
The figures above quote the first row. The difference is your own browser queuing the request and handing you the body, and it belongs to this machine rather than to the network.
A run measures the path between this tab and the nearest edge node holding this site. It cannot follow the route beyond that node, so a slow game server on another continent will still look fine here.
How to run a ping test from a browser
Three runs answer three different questions, and the third one is where the culprit usually turns up.
Pick a run length and send the probes
Twenty probes take four seconds and answer “is the line up”. Fifty is the setting worth using by default, because a single unlucky probe cannot move a median built from fifty. A hundred and twenty runs for twenty-four seconds, which is the length you want when the problem is intermittent and a short run keeps coming back clean. Nothing needs allowing and no device is opened — the run starts the moment you press the button.
Read the median first, then the worst
The best figure is the floor your line can reach when nothing is in the way, and it is the number rival tools print on their own. The median is what you actually live with. The gap between the median and the worst probe is where a stutter comes from: a run reading 18 ms with a worst of 240 ms describes a connection that was briefly not there, and averaging those together would hide it.
Run it again while the line is busy
Start a large upload, a cloud backup or a console download, and send the probes a second time. If the median climbs from 20 ms to 300 ms, the queue in your own router is the problem rather than your provider — the fix is a router that manages its queue, not a faster plan. This before-and-after pair is the single most useful thing this page produces.
Technical specifications
| What is probed | A three-byte text file on this domain, requested under a URL string that has never been used before, so nothing can answer from a cache |
|---|---|
| Run lengths | 20, 50 or 120 probes spaced 200 ms apart — 4, 10 or 24 seconds of measuring |
| Give-up time | 2,000 ms. A probe still outstanding is written down as unanswered rather than waited for, so one stall cannot hold up the run |
| Figure reported | Request-sent to first-byte-back, from Resource Timing, with the whole wall-clock fetch shown beside it and the difference named as your own browser's overhead |
| Excluded from that figure | Name lookup, TCP connect and TLS — paid once on the first probe and displayed on their own rather than averaged into the run |
| Distance from an ICMP ping | Typically 5-20 ms above it on a warm connection: TLS records, HTTP framing and a cache lookup at the edge all sit inside this number and none of them sit inside that one |
| Data kept | None. Timings exist as numbers in this tab and go when you reload it |
| Price | Free, no signup, and no cap on how many runs you make |
Frequently asked questions
Why is this higher than the ping command in my terminal?
Because it is a different measurement wearing the same name. The ping command sends an ICMP echo request, which the operating system kernel at the other end answers immediately, ahead of any application. This page sends an HTTPS request, which has to be framed by HTTP/2 or HTTP/3, decrypted, matched to a route at the edge node, answered and framed again on the way back. All of that is real time you experience when you load anything, but it is work an ICMP echo never does, so expect a browser figure to sit roughly 5 to 20 ms above the terminal on a warm connection. A browser cannot open a raw socket, so no web page anywhere can do it the other way.
What counts as a good ping for gaming?
Under 50 ms to the server you are actually playing on, and the second half of that sentence is the part people skip. Below 20 ms nothing about the network will be noticeable in any genre. Between 20 and 50 ms a shooter still feels immediate. From 50 to 100 ms you start to notice hit registration deciding things a moment after you did, and above 150 ms competitive play stops being fair. What this page measures is the trip to a content edge that is almost certainly in your own country, so treat a good reading here as proof your local link is healthy rather than as your in-game number.
The first probe is always the slowest. Is something wrong?
No, and the panel breaks out exactly why. The first request of a run may still be paying for a name lookup, a TCP handshake and a TLS negotiation, which together cost one to three extra round trips before a single byte of the answer can come back. Every probe after it reuses that connection, so the timeline flattens after the left edge. If your first probe is 300 ms and the rest are 20 ms, you have watched a connection being built, not a fault.
Can I point this at a game server or another website?
No page can, and one that appears to is measuring something else. A browser will not open a raw socket, and a cross-origin request only completes if that server chooses to allow it, at which point you are timing that server's own response rather than the network path to it. Anything claiming to ping an arbitrary address from a web page is either timing an image that fails to load or asking its own backend to do the pinging and reporting the backend's result, which is a measurement from a data center rather than from your sofa.
My ping is low but the game still stutters. What else should I look at?
The variation rather than the average, and then the losses. A line that sits at 20 ms and occasionally jumps to 200 ms averages out beautifully and still ruins a firefight, which is what the jitter test on this site measures directly. After that comes loss: in a game there is no retransmission, so a missing update becomes a position correction you see as rubber-banding, and the packet loss test is built to expose the version of that a browser can reach.
Does the number change if I run it on Wi-Fi instead of a cable?
Almost always, by 1 to 5 ms on a quiet 5 GHz link and by far more on a busy 2.4 GHz one. A wireless radio is a shared medium: every device takes a turn, a collision means waiting a random interval and trying again, and a frame that fails is retried at the link layer before your operating system hears about it. That retry arrives as extra milliseconds, not as an error. Testing both ways on the same laptop, a minute apart, is the cleanest way to find out how much your radio is costing you.
Is anything about my connection recorded?
No. Each probe is an ordinary request for a three-byte file from this domain, and the timings it produces are held as numbers in this tab, used to draw the chart, and lost when you reload. There is no account attached to a run, no history kept between visits and nothing sent onward, which is why the Copy button exists at all — it is the only way a result leaves this page.
About round-trip time, and what this number contains
A round-trip time has a hard floor set by physics. Light in a glass fiber travels at roughly 200,000 km per second, which works out at 5 microseconds per kilometer in each direction, so a server 1,000 km away cannot answer you in less than about 10 ms however much you pay for the line. Every millisecond above that floor was spent on something: a frame waiting its turn on a shared Wi-Fi radio, a packet sitting in a queue inside your own router, a cable modem waiting for its scheduled transmit slot, and the work at the far end of turning a request into an answer. That is why a single number is a poor summary and a run of them is a diagnosis — the floor tells you where you are, and the spread above it tells you what is in the way.
The measurement here is honest about being a web measurement. The ping command sends an ICMP echo request that the remote kernel answers before any application sees it, which is why it is the lightest possible probe and also why it is not what your browser experiences. This page requests a real file over HTTPS from a Cloudflare edge node, so the figure includes TLS record processing, HTTP/2 or HTTP/3 framing, the routing decision at the edge, and the answer coming back through all of it again. The result is consistently higher than the terminal by something like 5 to 20 ms on a warm connection, and higher still on the first probe of a run, which is the one still paying for DNS and the handshake. Both numbers are real; they measure different things, and the one on this page is closer to what a page load or a video call actually costs. Anycast keeps the distance short — a request for this site is answered from the nearest of hundreds of edge locations rather than from one origin server — so a reading here describes your own access network far more than it describes the internet.
Once you have a median, the useful work is comparing it with itself. Run it on Wi-Fi and again on a cable. Run it quiet, then again while an upload is saturating the link: a median that climbs from 20 ms to several hundred is bufferbloat, a queue in your own equipment filling faster than it drains, and it is fixed at the router rather than by buying more bandwidth. If the average stays low but the connection still feels wrong, the fault is usually in the shape rather than the size, and the jitter test measures how far consecutive probes land from each other, while the packet loss test puts the line under a short burst and counts what fails to come back. If the line drops out entirely rather than slowing down, leave the connection status page open and it will timestamp each disappearance for you. And if every network reading is clean but the game still feels a beat behind your hand, the delay may not be on the wire at all — the monitor ghosting test shows what your panel does with fast motion, which is the other half of the same complaint.
Where the timings go
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
The probes themselves are ordinary requests for a small file on this domain, of the kind your browser makes to load any page. Their timings are read back from your browser’s own performance entries, kept as numbers for the length of the run, and discarded on reload — there is no run history and nothing to log in to that would give you one.