Ping any IP or website online — measure latency, packet loss, and jitter. Free, no signup.

Six dimensions returned per ping run. Latency and packet loss are the headlines; jitter, host info, and the security check round out a full diagnostic in a single response.

Ping is the first network diagnostic anyone reaches for, and for good reason — it answers four very different questions at once with a single tool:

• Is the host even up? If pings reach a server, the network path is intact and the OS is responding. Doesn't prove the application is healthy, but rules out the bottom-most layer of the stack as the culprit when something seems broken.
• How responsive is the connection? Latency directly affects every real-time experience — game-server input, VoIP delay, video-call lag, interactive SSH, even basic page-load feel. Average latency under 30ms feels instant; over 200ms feels noticeably sluggish.
• Is the path stable? Packet loss and jitter reveal problems that bandwidth tests miss completely. A 1 Gbps connection with 5% packet loss is functionally worse than a 10 Mbps connection with zero loss for anything interactive.
• Where is the target physically? Latency floors are a function of the speed of light through fiber — roughly 5ms per 1000km of distance. A ping much higher than expected for the geographic distance suggests routing problems, not bandwidth issues.
• Is this server worth using? For CDN edge selection, game-server choice, VoIP server selection — ping is the deciding metric. The 'closest' server geographically isn't always the lowest-latency one; network routing often beats raw distance.

We resolve the hostname (if not already an IP), send 10 ICMP echo requests, wait for replies with a per-request timeout, then compute statistics across the samples. Important caveat: the source of the pings is our edge node, not your browser — ICMP packets can't be sent from JavaScript for security reasons.

• Stage 1 — Resolve target If the input is a hostname, run a DNS A/AAAA query first. Most ping tools default to IPv4; we follow the same convention.
• Stage 2 — Send 10 ICMP echo requests Standard ping protocol (ICMP type 8). Spaced 200ms apart by default. Each request carries a unique sequence number so we can match replies to requests.
• Stage 3 — Wait for each reply Per-request timeout (typically 2 seconds). Replies that arrive after timeout count as lost. Replies arriving in the wrong order are matched by sequence number.
• Stage 4 — Compute statistics Min, max, average, and standard deviation (jitter) of the successful samples. Plus the failed/successful counts for packet loss percentage.
• Stage 5 — Enrich with metadata GeoIP lookup on the target, ASN/ISP identification, security/blacklist check. Same enrichment as the IP Lookup and My IP tools.
• Stage 6 — Composite quality rating Combined Excellent / Good / Acceptable / Poor based on the three core metrics. Latency under 80ms + loss 0% + jitter under 10ms scores Excellent.

All three metrics have well-understood thresholds for what's good, acceptable, and broken. The thresholds depend on what you're actually trying to do — competitive gaming demands tighter values than reading a website.

• Latency — under 30 ms (Excellent) Competitive gaming, low-latency trading, telesurgery, sub-perceptible interaction. Typical when pinging a nearby data center over fiber.
• Latency — 30 to 80 ms (Very good) Typical home broadband to a same-continent server. Indistinguishable from local for everything except the most latency-sensitive workloads.
• Latency — 80 to 150 ms (Good) Typical transcontinental traffic (e.g., US East ↔ Europe). Real-time apps work fine; competitive games feel slightly heavy.
• Latency — 150 to 300 ms (Acceptable) Transoceanic, satellite (LEO), or congested paths. Most apps still work; voice calls develop noticeable delay; competitive gaming becomes painful.
• Latency — over 300 ms (Poor) Either a routing problem, severe congestion, or a geostationary satellite link. Interactive apps suffer. Sustained values this high indicate a broken or capacity-constrained path.

• Packet loss — 0% (Perfect) Expected on a healthy wired connection. Wireless and mobile can occasionally drop a packet — anything 0% over 10 pings is excellent.
• Packet loss — under 1% (Normal for wireless) Occasional drops on Wi-Fi, mobile, and satellite are expected. Doesn't affect non-real-time apps; TCP retransmits seamlessly.
• Packet loss — 1% to 5% (Concerning) Something upstream is dropping traffic. VoIP audio breaks up, video calls pixelate, online gaming has rubber-banding. Investigation warranted.
• Packet loss — 5% to 15% (Bad) Real-time apps become unusable. Even TCP-based file transfers slow dramatically because retransmits stack up. Usually indicates a congested link or hardware fault.
• Packet loss — over 15% (Broken) The connection is functionally unusable for anything interactive. Either equipment failure, severe congestion, or active throttling.

• Jitter — under 5 ms (Excellent) Variation is below the threshold of perception for almost every application. VoIP and gaming feel smooth even at higher absolute latency.
• Jitter — 5 to 20 ms (Okay) Acceptable for most apps. Video calls compensate via jitter buffers; gaming is fine for non-competitive play.
• Jitter — 20 to 50 ms (Noticeable) VoIP audio quality drops, gaming becomes choppy even when average latency looks reasonable. Usually a symptom of congestion or wireless interference.
• Jitter — over 50 ms (Problematic) Real-time apps degrade severely. Jitter this high often coexists with packet loss on the same congested path.

Latency has a physical floor — the speed of light through fiber is roughly 200,000 km/s, so a perfectly-routed 1,000 km path has a 10 ms round-trip floor before any equipment delay. These numbers help you tell 'this ping is bad' from 'this ping is what physics allows':

• Local network (LAN) — under 1 ms Same building, same switch. Wired connections often show 0.1–0.5 ms; Wi-Fi typically 1–5 ms depending on contention.
• Same metro area — 1 to 10 ms City-level peering. Cable and fiber to a regional data center should land here. If you're seeing 50 ms to a local IP, something is wrong with your routing.
• Same country, well-routed — 10 to 40 ms US east-to-west: about 40–70 ms (continental width). UK-to-Germany: 15–25 ms. India north-to-south: 25–50 ms.
• Cross-continent (US ↔ Europe) — 60 to 100 ms Transatlantic cables run at near-perfect speed; the limit is geography. NYC ↔ London is about 75 ms on a good day.
• Trans-Pacific — 100 to 180 ms US West Coast ↔ Tokyo: ~100 ms. US West Coast ↔ Singapore: ~170 ms. Equator-crossing routes can add 20–30 ms due to cable topology.
• Antipodal — 200 to 300 ms London ↔ Sydney, NYC ↔ Perth: the physical floor is about 130 ms (one-way through fiber); real-world routes nearly double that due to indirect paths.

• Fiber to the home (FTTH) — under 5 ms first hop The lowest-latency last-mile available. Adds essentially nothing to the path beyond your gateway.
• Cable broadband — 10 to 30 ms first hop DOCSIS adds some latency vs fiber but is usually fine. The variation depends on neighborhood contention.
• DSL — 20 to 50 ms first hop Older copper-based broadband. Significantly higher than fiber/cable. Becoming rare in dense markets.
• 5G mobile — 5 to 30 ms When you're on a real 5G network (not 5G-marketed-as-5G LTE), latency can rival fiber. Highly dependent on tower proximity.
• 4G LTE — 30 to 80 ms Wireless adds latency regardless of speed. Variation is large depending on signal strength and tower load.
• Starlink (LEO satellite) — 25 to 60 ms Low Earth Orbit satellites are much closer than geostationary, so latency is comparable to cable. Variable depending on satellite handoff.
• Geostationary satellite — 500 to 700 ms GEO satellites are at 36,000 km altitude — that's a 240 ms round-trip floor before any equipment delay. Real-time apps are essentially unusable on these links.

If your ping to a specific server is consistently higher than you'd expect for the geographic distance, the cause is usually one of a small number of things. Ordered from easiest to hardest:

• Switch from Wi-Fi to wired Ethernet Wi-Fi adds 5–30 ms depending on signal strength, congestion, and adapter quality. For competitive gaming or critical video calls, a 50-cent Ethernet cable is the single biggest improvement available.
• Pick a closer server If the game or service offers multiple regions, the closest one is usually (but not always) the lowest latency. Test the alternatives — peering quirks sometimes make a 'further' server faster than a 'closer' one.
• Kill background bandwidth consumers Cloud sync, large downloads, video streams on the same network, system updates — all add latency to everything else. Quality-of-service (QoS) rules on the router help if you can't avoid them.
• Update or replace your router Routers older than ~5 years often have outdated firmware, weak CPUs that bottleneck under load, and degraded radios. A modern $80 router will outperform a 2018 flagship for almost every consumer workload.
• Switch your DNS resolver Doesn't reduce ping itself, but DNS resolution time affects perceived responsiveness on every new connection. Cloudflare's 1.1.1.1 and Google's 8.8.8.8 are typically faster than the ISP default.
• Try a different ISP route Different ISPs have different peering arrangements with different services. Your ISP may route to your favorite game's server via three extra hops; their competitor may route directly. Worth testing if alternatives exist in your area.
• Avoid VPNs (or use a good one) Most VPNs add 20–80 ms of latency by adding hops. A few gaming-focused VPNs (like ExitLag, NoPing) can actually lower latency for specific games by routing through better-peered paths than your ISP — mileage varies wildly by region.
• Don't play at peak hours Last-mile and ISP-backbone congestion peaks in the evening. The same ping that's 30 ms at 9 AM can be 90 ms at 9 PM on the same connection. Often not fixable, but worth knowing.

The ping result is available as JSON. Useful for uptime monitoring, deployment health checks, latency regression detection, and CDN-region selection logic. Free tier rate-limited per IP.

const res = await fetch(
  'https://api.domainscan.in/v1/ping?host=8.8.8.8'
);
const data = await res.json();

console.log(data.summary.avg_time);         // 0.24 (ms — from our edge)
console.log(data.summary.failed_pings);     // 0
console.log(data.summary.successful_pings); // 10
console.log(data.quality);                  // 'Excellent'
console.log(data.isp.isp);                  // 'Google'
console.log(data.isp.asn.number);           // 15169

// Per-attempt timings (useful for jitter analysis)
for (const attempt of data.attempts) {
  console.log(attempt.attempt, attempt.time, attempt.status);
}

// Optional query parameters: count (default 10), timeout (default 2000ms)

{
  "host":    "string (input — IP or hostname)",
  "target":  "string (resolved IPv4 if input was hostname)",
  "message": "Pinging <target> N times",

  "summary": {
    "host":             "target IP",
    "total_pings":      "integer",
    "successful_pings": "integer",
    "failed_pings":     "integer",
    "min_time":         "number (ms)",
    "max_time":         "number (ms)",
    "avg_time":         "number (ms)",
    "std_deviation":    "number (ms, jitter)",
    "packet_loss_pct":  "number (0–100)"
  },

  "attempts": [
    { "attempt": 1, "host": "...", "time": 0.341, "status": "reachable | timeout | unreachable" }
    /* one entry per ping */
  ],

  "quality": "Excellent | Good | Acceptable | Poor",

  "location": {
    "continent":         "string",
    "country":           { "code": "ISO 3166", "name": "string" },
    "registeredCountry": { "code": "...", "name": "..." },
    "state":             "string",
    "city":              "string",
    "location":          { "latitude": "number", "longitude": "number", "timeZone": "..." },
    "security":          { "isVPN": false, "isProxy": false, "isTorExitNode": false, "isHostingProvider": false }
  },

  "isp": {
    "isp":          "string",
    "organization": "string",
    "network":      "CIDR",
    "asn":          { "number": "integer", "organization": "string" },
    "type":         "ISP | Hosting | CDN | ..."
  }
}

Six patterns we see most often:

• What's a good ping for gaming? Under 30 ms is excellent and competition-grade. Up to 60 ms is fine for almost any game. 60–100 ms is playable for most titles but starts to hurt in fast-paced shooters. Above 100 ms, expect to lose every close encounter. Above 150 ms, even non-competitive play feels heavy. The single biggest gaming-ping improvement available is usually switching from Wi-Fi to wired Ethernet.
• What's a good ping for video calls and VoIP? Under 100 ms one-way (200 ms round-trip) is the threshold for natural-feeling conversation. Above that, the speaker-listener crosstalk becomes noticeable and people start talking over each other. Jitter matters as much as latency: a stable 150 ms feels better than a fluctuating 80 ms because the jitter buffer can absorb variance only up to a point.
• Why is my ping so high? Most common causes, in order of frequency: Wi-Fi instead of Ethernet (adds 5–30 ms); background bandwidth use (cloud sync, downloads, streams); evening congestion on shared infrastructure; ISP routing to that specific destination is poor; VPN adding hops; physical distance to the target server. Section 06 has the full troubleshooting checklist.
• What is jitter and why does it matter? Jitter is the variation in round-trip time across samples. A connection that pings 50 ms ten times in a row has zero jitter; one that pings between 20 and 80 ms has very high jitter even though the average is the same 50. Real-time apps care about jitter because they have to buffer for the worst case — a jittery 50 ms connection feels worse than a stable 100 ms one for voice and gaming.
• Why does this tool show different ping than my command line? Because this tool pings from our server, not your browser. Browsers can't send ICMP packets directly for security reasons. The latency reported here is `our edge node → target`, not `your machine → target`. To measure your own ping, run `ping <host>` from your terminal (macOS/Linux) or Command Prompt (Windows).
• Can I ping any IP or website? Mostly yes. Some servers and firewalls block ICMP (you'll see 100% packet loss). Public-facing infrastructure usually allows ping; corporate networks and security-conscious servers often don't. If pings fail to a host but the website loads fine, ICMP is blocked — the server is reachable, just not for ping specifically.
• Why does my ping vary at different times of day? Network capacity is shared. During peak hours (typically 7–11 PM local time), last-mile and ISP-backbone links handle dramatically more traffic than at 3 AM, and latency degrades accordingly. A connection that pings 30 ms at 6 AM may ping 90 ms at 9 PM on the same hardware. Off-peak times are the best baseline for what your connection is actually capable of.
• Is ICMP ping the same as the latency I see in a browser? Close, but not identical. ICMP ping measures the round-trip time for a tiny network packet. Browser-perceived latency includes TCP handshake (1.5 RTTs), TLS handshake (1–2 RTTs depending on version), HTTP request/response, and any application-layer processing on the server. A site with 50 ms ICMP ping typically has 150–300 ms before the first byte of the page renders — most of that gap is the protocol stack, not the network.