📶 Ping Tool - Network Connectivity Test Online

Ping Tool checks whether a host on the public Internet is reachable and how long a round trip to it takes. The classic ping utility sends ICMP Echo Requests and waits for Echo Replies; this page runs that probe from our servers rather than from your machine, which separates "the site is down" from "my network cannot reach it".

ICMP for IPv4 is defined in RFC 792, ICMPv6 in RFC 4443, and round-trip delay terminology in RFC 2681. Real ICMP needs raw-socket access, so it runs only through a registered network worker; without one the API falls back to an HTTP probe (see Limitations).

Supported inputs

• Target host: one hostname (example.com) or one public IPv4 or IPv6 address (API field target), with no scheme, port, or path. Names use ASCII letters, digits, dots, and hyphens, up to 253 characters with labels of at most 63; internationalized names need punycode (xn--) form.
• Packet count: 4, 8, 10, 20, or Continuous: how many probes the page runs, one API request and one ICMP echo per result line. Continuous runs until you click Stop.
• Interval: 1, 2, or 5 seconds between probes, timed in the browser.
• API only: packet (integer 1 to 10, default 1) is how many ICMP echoes a worker sends in one request, reported as their average; the HTTP fallback ignores it. worker_id pins the request to one registered worker; when more than one healthy peer exists the page shows a Request Server selector and sends the chosen id.
• Blocked targets: private, loopback, link-local, carrier-grade NAT, documentation, and other reserved IPv4 and IPv6 ranges, plus localhost and names ending in .local, .localdomain, or .internal or starting with test., are refused with HTTP 400 (see FAQ).

Output

Each probe appends one line to the results log: a local time stamp in your browser's locale format, then Reply from host: bytes=32 time=NNms TTL=NN, or an error such as Request timeout (>5s) or HTTP 400 (the status code, with a reason phrase only when the connection supplies one). host is the target name on the worker path and the resolved public IP on the fallback; bytes is always 32; time is the browser-measured API round trip, not the reply time (see FAQ); TTL is the value the API returns and 64 whenever it returns none, including a worker answer with no reply line to parse; the fallback sends 64 unless Cache-Control: max-age gives a value, clamped to 1 to 255. Every 2xx answer counts as received without reading the API success flag, so only API errors and the 5 second browser timeout show up as loss. The Statistics panel adds packets sent, received, and lost with the loss percentage and the minimum, maximum, and average time; Copy exports log and statistics as plain text. Under 50 ms is excellent, 50 to 100 ms good, 100 to 200 ms fair, over 200 ms poor.

The API returns JSON with success, target, host, packet, time in milliseconds (average ICMP reply time on the worker path, null when nothing answered; total HTTP response time on the fallback), ttl, method (remote_icmp or HTTP simulation), and an ISO 8601 timestamp. The worker path adds raw_output from the ping command; the fallback adds bytes (32) and status_code. Errors carry an error message: 400 for a missing, invalid, or blocked target, a name with no public address on the fallback path, or an unavailable requested worker; 408 when neither the HTTPS nor the plain-HTTP attempt gets an answer (refused, unreachable, or timed out); 503 when a worker is required but none is available.

Example

Enter example.com, keep 4 packets and 1 second, and click Start Ping. Four lines appear about a second apart, shaped like [time] Reply from example.com: bytes=32 time=95ms TTL=56, then Statistics reading Sent: 4, Received: 4, Lost: 0 (0%). The page sends one echo per line, so the same four echoes in a single worker-path API call look like this:

POST /api/tools/network/ping
{"target": "example.com", "packet": 4}

{
  "success": true,
  "target": "example.com",
  "host": "example.com",
  "packet": 4,
  "time": 11.42,
  "ttl": 56,
  "raw_output": "PING example.com (...) 56(84) bytes of data.\n64 bytes from ...: icmp_seq=1 ttl=56 time=11.4 ms\n...",
  "method": "remote_icmp",
  "timestamp": "2026-09-10T12:00:00+00:00"
}

Limitations

• ICMP only through a worker. Without a worker the server makes one HTTP GET to https://target (plain http:// for IP literals), retries over plain HTTP if HTTPS fails, and follows no redirects. Each attempt has a 5 second idle timeout and a 10 second cap, so the pair can occupy the server for up to 20 seconds, while the page abandons its own request after 5 seconds. Any HTTP status counts as reachable, and a host with no web server is reported unreachable even when it answers ICMP.
• IPv6 literals on the fallback path. An IPv6 address passes validation, but the fallback builds the probe URL without brackets, so it is reported unreachable unless a worker handles it.
• Rate limits: anonymous callers get 5 requests per minute, 30 per hour, and 100 per day, with a CAPTCHA after 15 in an hour; signed-in users get 10, 60, and 300. Each result line is one request, so an anonymous run shows HTTP 429 error lines and a countdown notice from the sixth line in a minute onward.
• A failed ping does not prove a service is down, and a successful one does not prove that HTTP, SSH, DNS, or TLS works: firewalls, hosts, and cloud providers often block or rate-limit ICMP and traffic from data centre ranges. Use Traceroute, the Website Status Checker, and service-specific checks for deeper troubleshooting.

Browser or server processing

This tool is server-side only; your browser sends nothing to the target. Each result line posts target and packet: 1 (plus worker_id when a peer is selected) to /api/tools/network/ping. A registered network worker runs ping -c 1 -W 5; without one the web server resolves the name and makes the HTTP GET described under Limitations with the User-Agent OnlineCyberTools Ping/1.0. The target sees our infrastructure rather than your address, the hostnames you enter are visible to this service and the worker's resolver, and requests are logged for abuse prevention.

FAQ

Is this a real ICMP ping?

Only through a network worker, which runs the system ping command and reports "method": "remote_icmp" with the raw output; without one the API sends an HTTP GET and reports "method": "HTTP simulation". The log shows both the same way, so check the API method field when the distinction matters.

Why does ping succeed here but time out from my network?

The probe leaves from our server or worker, so it takes a different route through different firewalls: your network or ISP may filter ICMP, or the target may block your region. The reverse happens too, when a host blocks data centre ranges or, on the fallback path, runs no web server.

Why are private IP addresses and localhost rejected?

The probe runs on our infrastructure, so 192.168.1.1, 127.0.0.1, 169.254.169.254, or localhost would reach our internal network rather than yours. On the HTTP fallback the server resolves the name first as well and refuses any name whose addresses are not public. Ping internal hosts from a machine inside that network.

Why is the time higher than ping in my terminal?

The page measures the whole API request: your connection to this site, the server, the hand-off to the worker, and the probe itself. A terminal ping measures only the last part, so compare the API time field, which holds the ICMP average or HTTP response time.

References

• RFC 792: Internet Control Message Protocol
• RFC 4443: ICMPv6 for the Internet Protocol Version 6 (IPv6) Specification
• RFC 2681: A Round-trip Delay Metric for IPPM