Why Two Ping Tests Give You Two Different Numbers

A command-line ping sends an ICMP echo request — a bare network-layer packet that the target answers as fast as its stack allows. A browser cannot send one, because web pages have no access to raw sockets, so a browser-based test times a full HTTPS round trip instead. That adds request handling, server-side work, and browser scheduling on top of the pure network delay, which is why a browser reading typically sits a few milliseconds above a terminal ping to the same region. The absolute figure differs; the pattern — which region is closest, whether the line is stable or spiky, whether tonight is worse than last night — tracks reality closely.

What an ICMP Echo Actually Is

ICMP is the Internet Control Message Protocol, a companion to IP used for diagnostics and error signalling rather than for carrying application data. The ping utility sends an ICMP type 8 packet (echo request) and waits for a type 0 packet (echo reply). There is no connection to establish, no encryption to negotiate, and no application to wake up. The target machine's network stack recognises the packet and answers it, usually in kernel space.

That minimalism is the point. An ICMP round-trip time is about as close to raw path latency as an ordinary computer can get: propagation delay through fibre and copper, serialisation delay at each link, and queueing delay in the routers along the way. If your question is "how long does a packet take to reach this IP address and come back," this is the cleanest instrument available. Our guide to checking ping from the Windows command line covers reading that output properly.

Why a Web Page Cannot Send One

Emitting an ICMP echo requires a raw socket — a socket that lets a program write its own IP-level packet headers. On most operating systems that is privileged: it needs root, administrator rights, or a specific capability granted to the ping binary. Browsers deliberately expose nothing of the sort. JavaScript on a page can make HTTP requests, open WebSockets, and use WebRTC data channels, and that is the entire toolbox. No browser API emits an ICMP packet, and none will, because giving arbitrary websites the ability to craft raw packets would be a security disaster.

So every browser-based latency test — ours included — measures something adjacent. The standard approach is to time an HTTPS request to a small endpoint hosted in a specific region, repeat it, and report the round-trip times. That is exactly what CheckPing does: warm HTTPS round trips from your browser to nearby cloud endpoints, sampled repeatedly so you see both the typical value and the spread around it.

What Sits On Top of the Network Round Trip

An HTTPS round trip contains the network path plus several layers of software. Knowing the layers tells you where the extra milliseconds come from.

TLS session state. A brand-new TLS connection needs a handshake, costing one or more extra round trips before any useful data moves. Warm measurements reuse an established connection, so the handshake is paid once and excluded from the samples that matter. This is why a well-built browser test discards its first request.
HTTP request handling. The server parses headers, routes the request, and generates a response. Even an endpoint that returns a few bytes does real work — sub-millisecond on a tuned service, but not zero.
Server-side processing and load balancing. Cloud endpoints usually sit behind a load balancer or edge proxy. Each internal hop is fast, but it is another queue the request passes through.
Browser event-loop scheduling. Timing runs on the main thread. If the page is busy rendering, or the operating system deschedules the tab, the timestamp you record can trail the moment the bytes actually arrived. Timing APIs are precise, but several browsers deliberately coarsen them to mitigate side-channel attacks.
Your local software stack. The request traverses the browser's network process, the OS TCP/IP stack, and any VPN, proxy, or security software you run — none of which a kernel-generated ICMP echo passes through in the same way.

Stacked together, these produce a fairly consistent additive offset rather than random noise. That distinction matters, because a consistent offset preserves comparisons. If Frankfurt reads 18 ms and Ashburn reads 96 ms in the browser, Frankfurt is genuinely far closer, even if a terminal ping would have said 14 ms and 92 ms.

The Case Against Trusting Raw ICMP Blindly

There is a mirror-image problem most players never hear about: routers and servers routinely treat ICMP as second-class traffic. Packets destined for a router's own CPU are handled at lower priority than packets being forwarded through it, and many operators rate-limit ICMP replies to blunt floods and scanning. Some hosts drop echo requests entirely.

The consequences are easy to misread:

A middle hop in a traceroute showing 90 ms and 20% loss while every later hop looks clean is almost always rate limiting, not a fault. Only loss that persists to the final destination counts.
A server that answers ping slowly may serve real game traffic much faster, because forwarded packets never touch the slow control-plane path.
A target that ignores ICMP altogether returns "request timed out" while being perfectly reachable over TCP or UDP.

So ICMP is simultaneously the purest measurement of the network path and the measurement most likely to be distorted by policy. Neither tool is unconditionally more accurate. They answer different questions.

Comparison: ICMP Ping, Browser HTTP Ping, In-Game Ping

Property	ICMP ping (terminal)	Browser HTTP ping	In-game ping counter
What it measures	Round trip of a bare network-layer echo packet	Round trip of a warm HTTPS request to a regional endpoint	Round trip to the actual game server, as that game defines it
Transport	ICMP over IP	TCP or QUIC, with TLS	Usually UDP, often with the game's own timing logic layered on
Reading versus true path latency	Closest available to raw path RTT	A few milliseconds higher	Varies by title; some counters fold in tick or frame timing
Can target the real game server	Only if it answers ICMP and you know the IP	No — it measures cloud endpoints in the same region	Yes, by definition
Main distortion risk	Rate limiting and deprioritised control-plane handling	Software overhead above the network layer	Undocumented methodology that differs between games
Setup required	A terminal and the correct hostname or IP	Open a page	Enable the overlay and be in a match
Best used for	Path diagnosis, packet loss hunting, hop-by-hop analysis	Fast region comparison, before/after checks, spotting instability	The number that actually governs your gameplay

Which Number to Trust, and When

Checking whether your connection is healthy right now. Use a browser test. It takes seconds, needs no setup, and repeated samples reveal jitter as well as the average. Our walkthrough on how to read ping test results explains what the spread is telling you.
Comparing two server regions before you commit to one. Use a browser test. Both regions get measured by an identical method, so the software offset cancels out and the ranking is trustworthy even though the absolute values are not exact.
Judging whether a change you made helped. Use a browser test, run before and after. Consistent methodology beats absolute precision for any A/B comparison.
Hunting packet loss or a bad hop. Use ICMP tooling — ping, pathping, or mtr. Only these show where along the route the problem begins, and only these produce evidence an ISP will act on.
Setting expectations for a specific match. Use the in-game counter. It is the only figure measured against the server you are actually playing on, and it is the one your hit registration answers to.

Where Browser Testing Wins Outright

Accuracy is not the only axis. A browser test wins on three practical dimensions that matter more often than a two-millisecond discrepancy.

It works everywhere. You can run it on a phone, a console browser, a work laptop with a locked-down shell, or a friend's machine, without installing anything or knowing a hostname. It also works when you have no idea what IP your game actually connects to — which is most of the time, since matchmaking assigns servers dynamically and publishers rarely publish the address ranges.

It measures a realistic transport. Games do not send ICMP. They send application traffic over UDP or TCP, and that traffic is subject to the same shaping, queueing, and prioritisation policies as an HTTPS request. When your ISP's queue is full during an evening download, a browser test feels it. A deprioritised ICMP echo may or may not report the same story.

It is repeatable by non-experts. The single most valuable diagnostic habit is testing before and after one change at a time, and a test that takes five seconds and no typing is one people actually repeat.

How We Keep the Reading Honest

Three design choices matter more than chasing raw precision. First, we warm the connection before recording, so handshake cost does not contaminate the samples. Second, we take multiple samples and report the distribution rather than one lucky value — a 200 ms outlier caused by a background update is information, not an error to hide. Third, we describe the method openly rather than calling it "ping" and letting you assume ICMP.

What that means in practice: treat our number as a calibrated proxy. If it reports 22 ms to your nearest region, your true network latency is slightly lower and you are in good shape. If it reports 140 ms with wild variation, something is genuinely wrong, and a terminal ping plus a traceroute is the correct next step. For the concepts underneath all of this, start with what ping actually is, then run a live latency test and compare it against your own command line. The gap you see is the software stack — and now you know exactly what is in it.