Check whether a website or server answers, and how long its reply takes. This tool sends a short series of HTTPS requests from your browser and reports the response time, how much it varies, and how many requests came back.
Enter a domain name without https://, such as cloudflare.com. Five requests are sent, one after another.
A ping test tells you whether a host is reachable and how fast it replies. This one sends five HTTPS requests from your browser and reports the fastest, median and slowest reply plus how much they varied. A browser cannot send the ICMP echo packets the ping command uses, so it times real HTTPS requests instead — under 100 ms feels immediate for browsing.
What Is a Ping Test and What Does This Tool Do?
What does this tool do?
It sends five ordinary HTTPS requests to the host you enter, one after another, and times each one. The first request has to look up the name, open a connection and complete a TLS handshake, so it is normally the slowest. The four after it reuse that open connection, which brings them close to the real network round-trip time. From those four you get the fastest, middle and slowest reply, plus how much they varied.
That is a different measurement from the ping command in a terminal. Ping uses ICMP, a protocol browsers have no access to at all. What you get here is the latency a visitor's browser actually experiences when it talks to that host over HTTPS, which for a website is often the more relevant number.
Why is this useful?
It answers the first question in almost every connectivity problem: is the host replying at all, and if so, is it slow? A result that comes back in 40 ms rules out the server as the cause of a slowdown. A result that fails entirely tells you to look at DNS, HTTPS or a firewall rather than at the page itself. For throughput rather than latency, pair this with the Speed Test.
Who uses this tool?
• Web developers: confirm a freshly deployed site or API endpoint is answering over HTTPS.
• Network administrators: check from outside their own network whether a public host is reachable.
• Remote workers: tell the difference between a slow connection and a slow service before joining a call.
• Gamers and streamers: compare latency to different regional servers before committing to one.
• IT support teams: run a quick reachability check from a user's own browser before escalating a ticket.
How Do You Use This Tool?
1. Type a domain name into the Host name field, without https:// and without a path.
2. Press Test host, or just hit Enter. Five requests go out in sequence and take a couple of seconds.
3. Read the status line first: it tells you whether any reply arrived at all.
4. Compare the first request against the repeat requests. A big gap means most of the delay was connection setup, not the network.
5. Run it again a few minutes later, or against a second host, and use Recent checks to compare.
Example: a healthy result and a bad one
Testing cloudflare.com from a home fibre line typically returns something like: first request 180 ms, repeat requests 14 ms fastest, 16 ms median, 21 ms slowest, variation 7 ms, 5 of 5 successful. The 180 ms is DNS plus the TLS handshake; the real latency is the 14 to 21 ms.
Now compare a struggling connection to the same host: first request 900 ms, repeats 120 ms fastest, 410 ms median, 780 ms slowest, variation 660 ms, 4 of 5 successful. The average alone would look merely mediocre. The 660 ms variation and the missing reply are what tell you the connection is unstable, not just distant.
What a browser measures, and what it cannot
One number from a browser, versus per-packet detail and a hop-by-hop path from the command line. The browser figure is the one your visitors actually feel.
How Do You Read the Results?
Status
Whether at least one of the five requests came back. Responding over HTTPS means the host completed a TLS handshake and answered something; the tool times the reply rather than reading it, so a 404 or a 403 still counts as a response. No HTTPS response means none of the five got through, which is not the same as the server being switched off.
Host
The name that was actually tested, after cleanup. Whatever you paste is reduced to the bare host: the scheme, any path or query string, a port number and a trailing dot are all removed and capitals are lowered, so https://Example.com/page?a=1 is tested as example.com. The request always goes to port 443, which is why a port you type is dropped rather than used. The input field is rewritten to match, so this row and the field always agree.
Resolved address
The IP address the host name currently points to, looked up over DNS. If several addresses are published, the first is shown with a count of the rest. Your browser may pick a different one from the list, so treat this as the address family and network rather than the exact endpoint. When no address comes back the row separates the three reasons, because only two of them are about the host: the name is not in DNS at all, the name exists but publishes no A or AAAA record, or dns.google did not answer this browser, in which case the row is telling you about the lookup rather than about the host.
First request
The cold request. It includes the DNS lookup, the TCP connection and the full TLS handshake, so on a distant host it is routinely five to fifteen times the figure below it. This is the number a first-time visitor experiences.
Repeat requests
The fastest, median and slowest of the four requests that followed, all sent over the already-open connection. The median is the most representative single figure for latency to that host. Only replies that actually arrived are counted, so if two of the four fail these figures come from the two that answered, which is why the Successful requests row is worth reading beside them.
Variation
The gap between the fastest and slowest repeat request, the browser equivalent of jitter. A few milliseconds is normal. A gap in the hundreds means the path is congested or unstable, which degrades calls and games long before the average looks bad. If only one repeat request came back, this reads 0 ms because there was nothing to compare it with, not because the connection was perfect.
Successful requests
How many of the five got a reply inside the five-second timeout. Fewer than five is worth investigating, but it is failed HTTPS requests, not ICMP packet loss, so the percentage is not comparable to what ping reports.
What this tool cannot tell you
• It is not ICMP. Browsers cannot send echo requests, so there is no TTL value, no hop count and no true packet-loss figure here. For those, run ping or traceroute in a terminal. As reference, the usual starting TTL is 64 on Linux and macOS, 128 on Windows and 255 on many network devices, dropping by one at every router.
• A failure is ambiguous. No reply can mean the host is down, that it does not serve HTTPS on port 443, that its certificate does not match the name you typed, or that something between you and it is filtering the request.
• It only tests from here. Every figure is measured from your own device and network. A host that is slow for you can be fast from another country, and vice versa.
• It cannot see inside the path. If the delay is caused by one bad router four hops away, this test shows only the total. Traceroute is the tool that localises it.
When Would You Use This Tool?
Is it down, or is it me?
If a site fails here but others succeed from the same browser, the problem is at that host or on the path to it, not on your connection.
Post-deployment check
After a DNS change or a new certificate, confirm the host answers over HTTPS from outside your own network before telling anyone it is live.
Comparing regions
Test two or three regional endpoints in a row and pick the one with the lowest median, not the lowest single reading.
Diagnosing choppy calls
Steady median but large variation is the classic signature of jitter, which breaks voice and video while raw speed still tests fine.
Setting a baseline
Record a normal result while everything is healthy. Comparing against it later turns "feels slow" into a number you can act on.
Checking a CDN edge
A well-placed CDN answers in tens of milliseconds almost anywhere. A three-figure median suggests you are reaching an origin server instead of an edge.
What Response Times Should You Expect?
The ranges below are general baselines for the repeat-request figure on a stable connection, not measured averages, and they move with your ISP, the route and the time of day. The 150 ms threshold in the last row is the one-way delay limit recommended for natural conversation in ITU-T Recommendation G.114.
| Where the host is | Typical repeat request | What it means |
|---|---|---|
| CDN edge in your city | 5 to 20 ms | You are being served locally; this is as good as the public internet gets |
| Server in your own country | 15 to 50 ms | Normal for domestic sites and services |
| Mobile or 4G/5G connection | 30 to 120 ms, variable | Radio scheduling adds delay and, more noticeably, variation |
| Another continent | 120 to 280 ms | Mostly the speed of light through fibre; not a fault |
| Geostationary satellite | 550 ms and up | Well past the 150 ms one-way guidance, so real-time use suffers by design |
What If the Response Time Looks Fine but Pages Are Slow?
Latency and bandwidth are separate problems and they fail in different ways. A connection with a 20 ms median and 900 Mbps of throughput will still stall on a large upload if the upstream is saturated, and a satellite link with 600 ms latency can stream 4K perfectly well. If the number here looks fine but pages still feel slow, the next thing to measure is throughput with the Speed Test.
When a host fails here, the failure itself is the clue. Check first that the name resolves at all with the DNS Lookup tool: no A or AAAA record means nothing could have connected regardless of whether the server is running. If the name resolves but the request still dies, the problem has moved to HTTPS, the certificate, or a filter in between.
About the data
The timing requests go directly from your browser to the host you typed, so that host sees your IP address exactly as it would for any normal visit. The name resolution is done through Google's public DNS-over-HTTPS endpoint at dns.google. Nothing is stored on our servers; the Recent checks list lives only in your own browser and the Clear button deletes it.
What Other Tools Work With This One?
Frequently Asked Questions
Is this a real ping, like the ping command?+
No, and it does not claim to be. A browser cannot send the ICMP echo requests that the ping command uses. This tool sends ordinary HTTPS requests instead and times the replies, so the first figure includes DNS and TLS setup and every figure is a little higher than a true ICMP round trip would be.
Why does a site show no reply here when it opens fine in my browser?+
The request can fail for reasons unrelated to the server being down. The host may not answer on port 443, its certificate may not match the name you typed, or a firewall, VPN or browser extension may be blocking the request. A failed result means no usable HTTPS reply arrived, not that the machine is switched off.
Why is the first request so much slower than the rest?+
Before any data moves, the first request has to resolve the host name, open a TCP connection and complete a TLS handshake, which on a distant host is three separate round trips. The four requests after it reuse that connection, so they show network latency on its own. That is why the two are reported separately instead of averaged together.
What counts as a good response time?+
Under 100 ms feels immediate for browsing, and under 30 ms is excellent. ITU-T G.114 recommends keeping one-way delay under 150 ms for natural conversation, so round trips beyond roughly 300 ms start to feel laggy on calls and in games. A server on another continent can be slow by these numbers and still be perfectly healthy.
Why is there no TTL, hop count or packet loss figure?+
All three are properties of ICMP, which is unavailable to web pages. TTL and hop count are read from the IP header of an ICMP reply, and packet loss is counted across ICMP packets rather than HTTPS requests. If you need them, run ping or traceroute from a terminal.
What does the variation figure actually mean?+
It is the gap between the fastest and the slowest of the repeat requests, which is the browser equivalent of jitter. A few milliseconds means the path is steady. A gap in the hundreds means latency is swinging around, and that is what makes voice and video choppy even when the average looks acceptable.
Can I test a bare IP address instead of a host name?+
You can enter one, but it will usually fail. HTTPS certificates are issued for host names, so a request straight to an IP address is normally rejected during the TLS handshake even when the server behind it is running perfectly. Test the host name and use the resolved address shown in the results to see which IP you reached.
Is it acceptable to run this against a server I do not own?+
Five HTTPS requests are the same traffic an ordinary visitor generates by loading a page, so a normal test is unremarkable. Volume is what changes that: a flood of automated requests looks like an attack, which is one reason this tool sends a small fixed number per run rather than testing continuously.