What is ping?
Ping is a network diagnostic utility. A typical command-line ping sends an Internet Control Message Protocol (ICMP) Echo Request to a destination and waits for an Echo Reply. It can report whether a reply arrived and how much time the round trip took.
In everyday speech, “my ping is 30 milliseconds” usually means a measured network response time. That reported value is generally a round-trip time (RTT): the time from sending a request until its reply returns. It is not automatically a measurement of one-way travel time.
What is latency?
Latency is delay in communication between endpoints. A one-way latency describes the time for data to travel from one endpoint to another. Round-trip time includes a journey to the destination and the return of a response.
A round trip does not reveal the exact one-way delay in either direction. The forward and return paths may differ, and delays can also arise from queues, protocol handling, and endpoint processing. Dividing an RTT by two is only a rough assumption of symmetry, not a direct one-way measurement.
A round-trip measurement
Ping vs. latency
Ping and latency are related: ping tools can measure round-trip latency. One describes a diagnostic request or measurement; the other describes delay.
| Aspect | Ping | Latency |
|---|---|---|
| Meaning | A diagnostic request/response test; also used casually for its reported response time. | The time delay in communication between endpoints. |
| Measurement method | Traditional command-line ping typically uses ICMP Echo Requests and Replies. | Can be measured using different protocols and tools, including ping, HTTP, or application requests. |
| Common units | Milliseconds (ms), usually reported as round-trip time. | Milliseconds (ms) for network delays; one-way or round-trip, depending on the method. |
| Typical use | Check endpoint responsiveness and observe ICMP round-trip times. | Describe delay relevant to calls, games, remote work, and other applications. |
| What it tells you | Whether that diagnostic exchange received a reply and its measured RTT. | Delay for the specific path, endpoints, and method measured. |
| What it cannot establish alone | Latency to every service, one-way delay, or the cause of a problem. | Application performance everywhere, available bandwidth, or the cause of observed delay. |
How does PingWatch measure latency?
PingWatch runs in your browser and reports elapsed time for application-level request/response exchanges to a PingWatch endpoint:
- HTTP Ping sends a no-cache HTTP GET request to PingWatch. The browser uses its monotonic
performance.now()clock before the fetch and records elapsed time when the response headers arrive. The response body is then cancelled. - WebSocket Ping sends a small ping message over an already-open WebSocket connection to the selected PingWatch region. The server returns a matching pong, and the browser measures elapsed time with the same monotonic clock around that exchange. Initial connection setup is not included in each reading.
These are browser-to-server round-trip measurements, not native ICMP Echo tests. The app uses the HTTP and WebSocket interfaces available to a web page; it does not send ICMP Echo Requests.
The resulting values are not necessarily the same as command-line ping. ICMP, HTTP, and WebSocket can follow different routes or receive different handling. Browser scheduling and execution, network routing, server conditions, and application processing can all affect a reading. Results to PingWatch also do not represent latency to a game server or every website.
Why do ping results differ?
Two valid tests can report different values because they do not necessarily measure the same path or exchange. Differences may come from:
- Destination and geographic distance: a nearby endpoint usually involves a different physical path from a distant service, though distance is only one part of delay.
- Network routing: providers and networks may route traffic along different paths, and forward and return routes need not match.
- Congestion and Wi-Fi conditions: busy links, wireless interference, weak signal, or competing traffic can change response timing.
- Server processing and load: the destination must handle the request, and its current conditions can affect when it responds.
- Protocol and tool behavior: ICMP, HTTP, and WebSocket exchanges are not identical; browser scheduling and timer boundaries also matter.
For a useful comparison, repeat the same test against the same endpoint and note the protocol, time, and connection conditions.
What is a good ping?
“Good” depends on what you are doing, which endpoint is measured, and whether the value is a local, regional, or distant round trip. As a broad illustration, an RTT below about 30 ms is often described as low for a nearby endpoint; roughly 30–80 ms may be comfortable for many everyday interactive tasks; and values above 100 ms can be more noticeable in timing-sensitive applications. These are context, not universal cutoffs, standards, or guarantees.
Stability matters too. A consistent 70 ms RTT may feel more predictable than readings that jump between 20 and 150 ms. Jitter, spikes, failed probes, application buffering, and the actual destination can all matter alongside an average.
See What Is Jitter? for more about latency variation and how PingWatch estimates it.
How to test your connection with PingWatch
Open the PingWatch monitor and choose WebSocket Ping or HTTP Ping. Select a WebSocket region when you use that mode, then run a one-, five-, or ten-minute test with the browser tab visible.
- The latency chart shows successful measurements over time and marks detected spikes and failed requests.
- Jitter is the mean absolute change between adjacent successful readings in PingWatch's sequence, not RTP jitter.
- The Connection Quality Score combines latency, jitter, spike-based stability, and successful probe rate. It is a product-defined heuristic, not a standardized certification.
- The Connection Stability Timeline classifies observed probes and estimates stable or unstable durations from supported adjacent observations. It does not continuously verify the connection between probes.
All results describe the tested browser-to-PingWatch endpoint exchange. Failed application probes are not necessarily packet loss. For more detail, read the About PingWatch page. If results are inconsistent, see our connection troubleshooting guide.
Frequently asked questions
Is ping the same as latency?
Not exactly. Ping is a diagnostic exchange that can measure round-trip latency. Latency is the delay itself and can refer to one-way or round-trip time, depending on how it is measured.
Is lower ping always better?
Lower RTT can reduce delay to the tested endpoint, but it is not the only factor. Consistency, the route to the service you use, and application behavior also matter.
Why is my game ping different from PingWatch?
The game and PingWatch use different destinations, routes, servers, and potentially protocols. PingWatch measures its selected endpoint, not your game server.
Can a browser measure ICMP ping?
Ordinary web pages use browser APIs such as HTTP and WebSocket; they do not send native ICMP Echo Requests. PingWatch therefore reports HTTP or WebSocket round-trip times, not ICMP ping.
Does high ping mean slow internet?
No. Ping measures response delay to a particular endpoint, not download or upload bandwidth. High RTT can affect responsiveness without telling you how much data your connection can transfer per second.
What is the difference between ping and jitter?
Ping commonly refers to a diagnostic exchange or its RTT. Jitter describes variation across a series of measured delays. See the jitter guide for the calculation used by PingWatch.