A browser cannot send ICMP. No web API exposes raw sockets, so the ping command's actual protocol is unavailable to any web page. Each sample here is a real HTTPS request to the target — cache and credentials off, aborted at the timeout — and the figure is how long it took.
Does it agree with the ping command?
Mostly yes, and where it does not the reason is knowable. Measured on one machine, one network, the same minute:
| Host | ICMP min / avg | This tool | |
|---|
| carino.systems | 40.6 / 42.2 ms | 43 ms | agrees |
| github.com | 96.3 / 98.4 ms | 102 ms | agrees |
| cloudflare.com | 4.9 / 7.0 ms | 34 ms | 5× |
| www.cloudflare.com | 4.9 / 7.0 ms | 22 ms | better |
The first two match ICMP to within a few percent. The third does not, and the measurement is not at fault: cloudflare.com/favicon.ico answers 301 and redirects to www.cloudflare.com. The browser follows it, so every probe pays a second request to a second host — a fresh DNS lookup, TCP handshake and TLS handshake on the first one, and an extra round trip on every one after. Probing the final URL directly cuts it from 34 ms to 22 ms.
So why is mine still higher than the terminal?
- The target redirects. Check with
curl -sI https://host/path. A 301 or 302 means you are timing two hops. Probe the URL it points at.
- You are reading a total, not TTFB. Where a server sends no
Timing-Allow-Origin header the browser hides the phase breakdown, so the figure is the whole request — including the server's own think time and the transfer. Those rows are marked total only. Rows marked TTFB are time-to-first-byte, which is mostly propagation delay.
- ICMP and HTTPS may not talk to the same machine. An echo request is answered by the kernel of the first anycast node that sees the packet. An HTTPS request has to reach something that can actually serve the path, and on a CDN that can be a different machine in a different city.
- The first request is not the steady state. It pays DNS plus the TCP and TLS handshakes — routinely three to five times the warm round trip, which is why Drop the first request is on by default: it is sent to open the connection and then not recorded at all. Turn it off and it is kept, shown on each card and in the exports flagged cold, and still excluded from every statistic on this screen.
Cross-checks on the same screen
Downlink not measured
Interface not published
Reported —
Public host not measured
STUN is a single UDP exchange with no TLS and no server-side work — the closest a browser gets to a raw round trip. It is the floor: what a target reads above it is protocol and application overhead, not distance. Downlink is measured before the run and never during it, because a saturated link has a full queue and a full queue adds delay to everything behind it.
The STUN exchange is the one probe that leaves for a host you did not name. It runs when you press Start or Test, never on page load, and it goes to
Why it cannot name your network interface
There is no web API for it, and that is deliberate rather than missing. Chrome and Firefox replace WebRTC host candidates with a random <uuid>.local name precisely so a page cannot enumerate the network it is on. navigator.connection.type is the nearest thing and only Chromium on Android and ChromeOS populates it; on desktop it is undefined, and Firefox and Safari do not ship the API at all. The Interface field reads not published rather than guessing from the effective type.
Reading a saved log
Log file mode reads output the ping command already wrote — real ICMP round trips, taken by whatever machine ran it. The file is read in this tab and never uploaded. Linux, BusyBox, macOS, Windows in any language, PowerShell Test-Connection and this tool's own CSV are recognised automatically, as are timestamps added by ts, $(date) or Get-Date. Files saved by cmd in an OEM code page or by PowerShell in UTF-16 are decoded correctly.
- Linux prints nothing for a lost packet. A sequence number that never appears is counted as lost and marked inferred; packets lost after the last reply are recovered from the summary's
packets transmitted.
- Most logs have no clock. Without
ping -D or a wrapper the time axis is estimated from the sequence number and the interval you choose, and the strip says so.
- ping's own summary is a free check. Where one is printed, the parsed counts and min/avg/max are compared against it, run by run.
- mdev is not jitter. ping's
mdev is a standard deviation; the jitter here is RFC 3550's mean change between consecutive replies. The cards show both.
Other things worth knowing
IP addresses. A few answer — 8.8.8.8, 1.1.1.1 and 9.9.9.9 serve HTTPS with certificates valid for the address — but you are timing their web server, not the address's reachability. Most others have no HTTPS listener and come back unreachable, which says nothing about whether the host is up.
A 404 is a perfectly good round trip and is timed like any other reply, so the probe path does not have to exist. Some targets will log 404s in devtools; the measurement is unaffected.
Loss is counted, not hidden. A probe that times out or never connects increments loss and breaks the chart line, and a target that fails every request reads 100% loss rather than showing an empty graph.
Everything stays in this tab: targets and the client identifier are kept in this browser's local storage, samples exist only in memory until you export them, and no result is sent anywhere. The requests themselves obviously do reach the hosts you name.