Why can't browsers do real ICMP ping?

ICMP (Internet Control Message Protocol) requires raw socket access that browsers intentionally block for security. This tool uses HTTP fetch timing as a practical approximation of network latency.

What does 'packet loss' mean here?

If a fetch request times out or fails with a network error, it counts as a lost packet. The packet loss percentage is the proportion of failed requests out of total attempts.

Why are some sites unreachable?

Many servers block CORS preflight requests or do not respond to OPTIONS requests from foreign origins. If a site blocks cross-origin requests you will see 100% packet loss even if the site is up.

How accurate is the latency measurement?

Browser fetch timing measures total HTTP round-trip time including TCP handshake, TLS negotiation, and server response — typically 5-50ms higher than raw ICMP ping due to protocol overhead.

Network 무료 회원가입 불필요

Ping Test

Visual network ping simulator with latency graphs

도구를 불러오는 중…

이 도구에 대해

Simulate pinging any domain or URL directly from your browser using the Fetch API for timing. See latency in milliseconds for each of 4 requests, packet loss simulation, and min/avg/max statistics — all visualised in a live-updating SVG bar chart. Note: browsers cannot send raw ICMP packets, so this tool uses HTTP OPTIONS/HEAD request timing as a close approximation of network round-trip time.

사용 방법

1 Enter a domain name or full URL (e.g. example.com or https://example.com).
2 Click 'Start Ping' to begin sending 4 timed fetch requests.
3 Watch the SVG bar chart update live as each request completes.
4 View the summary showing min, avg, max latency and packet loss percentage.

What this tool measures — and what it can't

A traditional ping command sends an ICMP Echo Request packet to a host and times how long the Echo Reply takes. Browsers, for security reasons, cannot send raw ICMP packets at all. So this tool measures something related but distinct: it fires an HTTP request at a URL using the browser's Fetch API and times how long the round trip takes with performance.now(), a high-resolution clock. It repeats this four times and reports the latency of each attempt plus min, average, and max. The number you get is therefore an HTTP round-trip time, not a pure ICMP ping — it includes DNS resolution (on the first request), the TCP handshake, and TLS negotiation for HTTPS sites, all of which add overhead a real ping does not have. Expect these readings to run higher than a command-line ping to the same host.

How a single measurement is taken

For each of the four attempts the tool does the following: it starts a timer, sends a HEAD request in no-cors mode with caching disabled, and stops the timer when the request settles. A HEAD request asks only for headers, not the page body, so it transfers as little as possible. The no-cors mode lets the request go out even to servers that don't grant cross-origin permission — but it means the response is opaque: the tool can see that the round trip completed and how long it took, but cannot read status codes or content. A 5-second timeout guards each attempt; if the request doesn't resolve in time, an AbortController cancels it and that attempt is recorded as a loss.

Reading the chart and the loss figure

Each attempt becomes a bar in the SVG chart, color-coded by latency: green under 100 ms (snappy), amber from 100 to 300 ms (noticeable), and red above 300 ms (sluggish). A failed or timed-out attempt shows as a red "Lost" bar. The packet loss percentage is simply the fraction of the four attempts that failed. Here is the crucial caveat: an apparent 100% loss frequently means the target server refused the cross-origin request, not that the network is broken. Many sites reject requests from other origins, which the browser surfaces as a failed fetch indistinguishable from a genuine timeout. So treat 100% loss as "couldn't measure this host from a browser," not necessarily "host is down."

A worked example

Enter example.com (the tool prepends https:// automatically if you omit the scheme). Suppose the four attempts return 142, 38, 41, and 45 ms. The first is higher because it pays the one-time cost of DNS lookup and the TLS handshake; once the connection is warm, subsequent attempts are faster. The stats then show min 38 ms, max 142 ms, average (142+38+41+45)/4 = 67 ms, and 0% loss. The wide gap between the first and later attempts is normal and is itself informative — it isolates connection-setup cost from steady-state latency.

Genuine use cases

Quick reachability check. Confirm from your own browser whether a public site responds and roughly how fast, without opening a terminal.
Comparing endpoints. Run it against two CDN or API URLs to get a rough sense of which responds faster from your location.
Spotting jitter. Four readings that swing wildly (e.g. 40, 300, 50, 280) hint at an unstable connection or an overloaded server.
Teaching networking. The first-attempt penalty is a clean, visible demonstration of DNS and TLS setup cost.

Tips and common mistakes

Don't trust the absolute number as a true ping. Because it bundles TCP/TLS setup, this overstates raw network latency. Use it for relative comparison, not as a substitute for ICMP ping when precision matters.
100% loss often means CORS, not downtime. Test a site you know is up; if it also shows loss, the cause is cross-origin refusal, a browser limitation.
The first reading is always the slowest. Judge ongoing latency by the second through fourth attempts, which reuse the warmed connection.
Include the full URL when in doubt. The tool defaults to HTTPS; an HTTP-only host needs you to type http:// explicitly.
Background tabs throttle timers. Keep the tab focused while testing, as browsers slow timers in inactive tabs and can distort readings.