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. As a rough guide, under about 100 ms generally feels responsive 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 usually the slowest. The four after it usually reuse that open connection, which brings them close to the network round-trip time plus the host's own processing 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 makes the server's response time an unlikely cause of a slowdown, though not the only possible one. 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
The numbers below are illustrative, not a measurement of any real host. Imagine a test of example.com on a fast home line: first request 180 ms, then repeats of 14, 15, 17 and 21 ms, which the page reports as 14 ms fastest, 16 ms median, 21 ms slowest, 7 ms variation and 5 of 5 successful. The 180 ms is mostly DNS plus the TLS handshake; the latency to the host is closer to the 14 to 21 ms.
Now imagine a struggling connection to the same host: first request 900 ms, one repeat failing, and the other three at 120, 410 and 780 ms. The page would report 120 ms fastest, 410 ms median, 780 ms slowest, 660 ms variation and 4 of 5 successful. The 660 ms variation and the missing reply are what point to an unstable connection rather than one that is merely 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.
This tool compared with the ping command
| Aspect | This tool (HTTPS from your browser) | The ping command (ICMP) |
|---|---|---|
| What is sent | Ordinary HTTPS requests to port 443. | ICMP echo requests, defined in RFC 792. |
| First number | Usually includes DNS, TCP and TLS setup, so it is often much higher than the rest. | Usually just one network round trip. |
| Includes host processing | Yes. The host has to produce an HTTPS reply. | Usually little, because the network stack answers. |
| TTL and packet loss | Not available. It counts failed HTTPS requests instead. | TTL is shown, and loss is counted across ICMP packets. |
| Hosts that block ICMP | Can still be measured if they serve HTTPS. | May show no reply even when the site works. |
| Closest to what a visitor feels | Generally closer for websites. | Better for raw network latency and for path diagnosis with traceroute. |
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 should 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 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. One limit: if the resolver replies with an error such as a server failure instead of a clean empty answer, the row can still read "No A or AAAA record published", so confirm with the DNS Lookup tool when that matters.
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 often several 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 usually 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 can mean the path is congested or unstable, which can degrade calls and games 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.
Example inputs and what the tool does with them
These results come from the page's own host-cleaning code run on each input. They show the name that is tested, not a live result for any host. Unlike the DNS Lookup tool, this page does not strip a user name before an @ sign, so enter the host name alone.
| You type | Host tested | Outcome |
|---|---|---|
| https://Example.com:8080/page?a=1 | example.com | Scheme, port, path, query string and capitals removed. The request goes to port 443. |
| Example.COM. | example.com | Trailing dot removed and capitals lowered. |
| 192.0.2.10 | 192.0.2.10 | Treated as a bare IP address, so DNS is skipped. The HTTPS certificate check often fails for addresses. |
| [2001:db8::1]:443 | 2001:db8::1 | Brackets and port removed. Treated as a bare IPv6 address. |
Example timings and the figures the page reports
The sample times below are made up to show the arithmetic. The reported figures were computed with the same minimum, median and maximum logic the page uses.
| Five request times (ms) | First request | Repeat requests | Variation | Successful |
|---|---|---|---|---|
| 180, 14, 15, 17, 21 | 180 ms | 14 fastest, 16 median, 21 slowest | 7 ms | 5 of 5 |
| 900, 120, failed, 410, 780 | 900 ms | 120 fastest, 410 median, 780 slowest | 660 ms | 4 of 5 |
| 250, failed, failed, 48, failed | 250 ms | 48 fastest, 48 median, 48 slowest | 0 ms, only one sample to compare | 2 of 5 |
In the first row the four repeat times are 14, 15, 17 and 21, so the median is the average of the middle two, 15 and 17, which is 16.
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, commonly seen starting TTL values are 64 on Linux and macOS, 128 on Windows and 255 on many network devices; they vary by system and setting, 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.
• It does not separate every DNS error. The address lookup reports a missing name and an empty answer, but a resolver error such as a server failure can be shown as no record published. Use the DNS Lookup tool for the exact status.
How the Response Time Is Calculated
The test runs in two phases that do not share data: a DNS lookup that produces the Resolved address row, and five timed HTTPS requests that produce every other figure. A failure in the first phase does not stop the second, so a host whose name does not resolve still gets a status line and a success count, both of which will read as failed.
Phase 1: the host name is cleaned, then resolved
Whatever you type is reduced to a bare host before anything else happens. The scheme (https://), any path or query string, a port number and a trailing dot are stripped, and capitals are lowered, so https://Example.com:8080/page?a=1 is tested as example.com. The input field is rewritten to match so the two should not disagree. If what remains is already an IP address, DNS is skipped and the address is used as it stands.
For a name, the lookup goes to Google's public DNS-over-HTTPS endpoint at dns.google. An A query is made first; only if it returns no addresses is a second query made for AAAA. The first address in the winning list is shown, with a count of the rest beside it.
The lookup can end in one of four ways, and the row states which one happened rather than collapsing them into a single "no address" message:
- An address was returned. The first one is shown, marked IPv4 or IPv6.
- The name does not exist in DNS (a DNS status of 3, NXDOMAIN). The row reads The name does not exist in DNS.
- The name exists but publishes no A or AAAA record. The row reads No A or AAAA record published.
- dns.google did not answer this browser. The row reads Not known and names the cause. This is the one outcome that is a fact about the lookup rather than about the host, and reporting it as a name that does not resolve would blame the host for a problem on this side.
Phase 2: five HTTPS requests, timed one at a time
Five requests are sent in sequence to https://<host>/?myipshow-check=<random>, each with a five-second timeout and a 120 millisecond pause between one finishing and the next leaving. Each is timed from the moment the request is issued to the moment the reply is received.
Nothing about the page contents is read. Each request is issued with the browser's no-cors mode, so the response comes back opaque and unreadable — but an opaque response is still proof that the whole round trip completed, without needing the host to send CORS headers it may not send to a third-party tool. This is what makes the test work against any host rather than only ones configured for cross-origin requests.
Each request also asks the browser not to reuse a cached copy (cache: no-store) and carries a random query string, so a cached or intermediate copy is less likely to answer in place of the host. The host may still log that query string.
The first request carries the DNS lookup, the TCP connection and the full TLS handshake, so it is reported on its own as First request. The four after it usually reuse the open connection and are reported together as Repeat requests, and those four feed the summary figures:
- Fastest and slowest are the minimum and maximum of the four samples.
- Median is the middle value once the four are sorted. When the count is even, the two middle values are averaged. The median is used rather than the mean so a single stalled sample cannot pull the figure.
- Variation is the difference between the fastest and slowest sample — a subtraction, not a standard deviation or an average change. If only one of the four returned, this reads 0 ms because there is nothing to compare it against, and the page says so rather than passing it off as a steady connection.
What counts as a response
A request counts as successful if any response arrives, whatever its status code. A 404 or a 403 still means a live server answered on time, and treating those as failures would misreport a perfectly reachable host as down. The Successful requests row counts all five requests, including the cold one, so a run that lost only the first still reads four out of five. That count is failed HTTPS requests, not ICMP packet loss, and the two percentages are not interchangeable.
A request that never gets a reply is settled by the five-second timer: the outstanding fetch is aborted and the sample is recorded as a failure with the full timeout as its duration. That is what stops one hung request from stalling the whole run behind it.
What is not calculated
No TTL, no hop count, no packet-loss percentage — all three are properties of ICMP, which browsers have no access to. No per-hop breakdown either, so if the delay is caused by one bad router four hops away, this test sees only the total. And no server-side timing is separated out: the browser times the reply as it arrives, so the figure includes the host's own processing time as well as the network round trip.
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 can break 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 figure in the last row comes from ITU-T Recommendation G.114, which indicates that most applications are not significantly affected while one-way delay stays below it.
| Where the host is | Typical repeat request | What it means |
|---|---|---|
| CDN edge in your city | 5 to 20 ms | You are probably being served locally; this is about as good as the public internet gets |
| Server in your own country | 15 to 50 ms | Common for domestic sites and services |
| Mobile or 4G/5G connection | 30 to 120 ms, variable | Radio scheduling can add delay and, more noticeably, variation |
| Another continent | 120 to 280 ms | Largely physical distance through fibre; not necessarily a fault |
| Geostationary satellite | Roughly 500 ms or more | One-way delay alone is past the 150 ms guidance, so real-time use is affected 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 often stream video acceptably. 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
Two sources feed this page. The response times are measured live in your browser: five HTTPS requests go directly to the host you typed, so that host sees your IP address as it would for any visit. The resolved address comes from Google Public DNS at dns.google. There is no fallback service; if dns.google cannot be reached, the address row says so and the timing test still runs.
Everything is fetched fresh each time you press Test host, and the DNS answer may come from Google's cache until the record's TTL runs out. The tool itself does not save results on a server; the Recent checks list lives in your own browser and the Clear button deletes it. Ordinary web hosting and analytics logs for visiting this page are separate from that.
The explanations on this page were last reviewed on October 2, 2026.
What Other Tools Work With This One?
Sources and Further Reading
These are the references behind the explanations on this page.
• MDN: Request.mode. Explains that in no-cors mode the response is opaque, so its headers and body are not available to JavaScript, which is why this tool times the reply instead of reading it.
• RFC 792: Internet Control Message Protocol. The specification of ICMP, including the echo request and reply that the ping command uses.
• ITU-T Recommendation G.114: One-way transmission time. Guidance on how one-way delay affects applications, including the 150 ms and 400 ms figures used on this page.
• Google Public DNS: JSON API for DNS over HTTPS. The interface used for the resolved address lookup, including the Status field that distinguishes a missing name from an empty answer.
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 the figures are usually 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 usually 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?+
As a rough guide, under about 100 ms generally feels responsive for browsing, and under about 30 ms is very good. ITU-T G.114 indicates that most applications are not significantly affected while one-way delay stays below 150 ms, and it gives 400 ms as an upper limit for general network planning. A round trip beyond roughly 300 ms can therefore start to feel laggy on calls and in games, although highly interactive uses can be affected by lower delays. A server on another continent can look 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 suggests the path is steady. A gap in the hundreds can mean latency is swinging around, which can make 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 often fail. HTTPS certificates are normally issued for host names, so a request straight to an IP address is usually 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 similar to the traffic an ordinary visitor generates by loading a page, so a single test is generally low impact. Volume is what changes that: a large number of automated requests can look like an attack, which is one reason this tool sends a small fixed number per run rather than testing continuously. Rules about automated requests vary by country and by a host's terms of use, so this is general information and not legal advice.
How the Ping Tool Works
What it measures: Whether a host responds and how long the response takes, in milliseconds.
What it is based on: Round-trip delay: the time for a request to reach a host and for the reply to return, as defined in RFC 2681. Cloudflare explains why distance, the number of network hops and congestion all add latency.
Limits of the result: One reading is noisy, so look at several. The result depends on where the test runs from and the route to the target, so it can differ from the ping command on your own computer. Some servers are set not to answer, so “no response” does not always mean a host is down.
Sources: RFC 2681 (round-trip delay) · Cloudflare: what is latency?
Last reviewed October 2026 · Editorial Policy · How our tools work
Ok
ReplyDelete