Ping measures the round-trip time for a packet to travel from your machine to a destination and back. That's the simple explanation. The nuanced explanation is what separates someone who can diagnose network issues from someone who just knows "my internet is slow."
What happens during a ping
The ping command sends an ICMP Echo Request packet to the target. The target's network stack receives it and sends back an ICMP Echo Reply. The time between sending and receiving is the round-trip time (RTT).
ICMP operates at the network layer (Layer 3). It doesn't use TCP or UDP. This means ping results tell you about network-layer connectivity but say nothing about whether a specific application port is reachable or whether the TCP handshake will succeed.
This distinction matters. A server can respond to ping while its web server is completely down. Conversely, many firewalls block ICMP, so a host can be fully functional but unreachable by ping.
What the numbers mean
A typical ping result shows four values: minimum RTT, maximum RTT, average RTT, and packet loss percentage.
For a server within the same city: 1-5ms
Same country: 20-50ms
Cross-continent: 100-200ms
Satellite connection: 500-700ms
These numbers are bounded by physics. Light in fiber optic cable travels at about 200,000 km/s (roughly two-thirds the speed of light in vacuum). New York to London is about 5,500 km. At 200,000 km/s, the one-way delay is 27.5ms. Round trip: 55ms minimum. Add routing hops, processing delays, and queuing, and 70-90ms is expected.
If you're seeing 300ms to a server that should be 50ms away, something is wrong. Either the packets are taking a suboptimal route (check with traceroute), or there's congestion at a network hop, or your ISP is having issues.
Jitter matters more than latency for real-time applications
Jitter is the variation in latency between packets. If your ping times are consistently 50ms, that's fine for a video call. If they're bouncing between 20ms and 200ms, the call will be choppy even though the average latency is acceptable.
Real-time applications use jitter buffers to smooth out variation. A jitter buffer introduces intentional delay (typically 20-60ms) to absorb timing variations. But if jitter exceeds the buffer size, packets arrive too late and are discarded, resulting in audio gaps or video artifacts.
This is why a wired connection almost always beats Wi-Fi for video calls. Wi-Fi introduces variable latency from channel contention, retransmissions, and signal quality fluctuations. The average might be similar, but the jitter is dramatically higher.
Packet loss is the silent killer
1% packet loss sounds trivial. It's not. TCP retransmits lost packets, but the retransmission adds at least one full RTT of delay for that data. On a connection with 100ms RTT and 1% packet loss, effective throughput can drop by 30-50% because TCP's congestion control interprets loss as congestion and reduces the sending rate.
For UDP-based applications (voice, video, gaming), lost packets are simply gone. No retransmission. At 1% loss, you lose one out of every hundred voice frames. At 5%, the call becomes unusable.
Browser-based ping limitations
Browsers can't send ICMP packets. They don't have raw socket access. So browser-based ping tools use one of several approximations.
The most common is measuring the time to load a small resource (a 1x1 pixel image or a tiny JavaScript file) from the target server via HTTP. This measures more than just network latency. It includes TCP handshake time, TLS negotiation (if HTTPS), and HTTP processing time. But for a relative comparison between different times or different servers, it's useful.
WebSocket-based ping is another approach. Once the WebSocket connection is established, sending a small message and measuring the response time gives a closer approximation to true ICMP ping, since the TCP connection and TLS session are already established.
I built a browser-based ping test at zovo.one/free-tools/ping-test that measures connection latency, jitter, and gives you a clear picture of your network health. It's not a replacement for command-line tools, but it's a fast way to check if your connection is performing as expected.
I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.
Top comments (0)