Calculate network latency between two cities, estimate distance from a ping RTT, and compute file transfer time. Free fiber latency calculator.
This latency calculator works out the network delay between two locations from first principles: it geocodes both places, measures the great-circle distance between them, divides by the propagation speed of the transmission medium, and applies a real-world factor for routing and equipment delays. It also runs in reverse — give it a measured ping time and it estimates how far away the far end can physically be — and it includes a file transfer calculator that combines bandwidth with latency to predict how long a copy will actually take.
The tool exists because ping times are governed by physics before they are governed by hardware. No amount of money buys a sub-40 ms round trip between London and New York over fibre, and knowing that number before you design a system saves a great deal of misplaced optimisation. Everything runs in your browser, and every calculation can be shared as a link that restores your inputs.
Distance comes from the haversine formula on a 6,371 km-radius sphere, which gives the great-circle distance between two sets of coordinates. One-way latency is then:
latency_ms = (distance_km / propagation_speed_km_per_s) × 1000
Round-trip time is double that, and the real-world figure multiplies the RTT by a factor you select. The medium determines the propagation speed:
| Medium | Speed used | Implied delay |
|---|---|---|
| Fiber optic | 200,000 km/s | ~5 ms per 1,000 km one way |
| Copper cable | 200,000 km/s | ~5 ms per 1,000 km one way |
| Wireless 5G | 200,000 km/s | ~5 ms per 1,000 km plus processing |
| Satellite (GEO) | 300,000 km/s | vacuum speed of light |
The 200,000 km/s figure for fibre is not arbitrary. Light travels at roughly 300,000 km/s in vacuum, but glass has a refractive index near 1.47, so light in a single-mode fibre core moves at about two-thirds of that. This is the single most important number in the tool: fibre costs you about 5 ms of one-way delay for every 1,000 km, or 10 ms of round trip.
Theoretical latency is a floor nobody reaches. Cable routes do not follow great circles, they follow rights of way, seabeds, and existing conduit. Every router, switch, optical amplifier, and firewall on the path adds processing and queuing delay. Traffic is often backhauled through a peering point in the wrong direction entirely. The multiplier accounts for all of it:
1.25× — excellent: a direct, well-provisioned private path.1.5× — very good: a short public internet path with good peering.2.0× — typical: the sensible default for general internet routes.2.5× — below average: indirect routing or congested transit.3.0× — poor: badly routed, congested, or heavily hop-laden paths.London to New York is about 5,570 km great circle. Over fibre at 200,000 km/s that is 27.9 ms one way and 55.7 ms theoretical round trip. At the typical 2.0× factor the tool predicts roughly 111 ms, which brackets the 70–80 ms real transatlantic RTTs seen on good carrier paths — those routes are better than typical, closer to a 1.3× factor, because the transatlantic cables are unusually direct. Sydney to London, at about 16,990 km, gives 170 ms round trip theoretically and around 340 ms at 2.0×, which is much closer to reality because that path is anything but direct.
Run the reverse calculation and the logic inverts usefully: a 28 ms ping over fibre implies a one-way path of about 14 ms, or roughly 2,800 km of glass at the theoretical limit — and realistically well under half that once routing overhead is accounted for. That is how you tell whether a CDN edge is genuinely local or whether your traffic is being backhauled to another continent.
The data transfer tab makes the bandwidth-versus-latency distinction concrete. Bandwidth is capacity; latency is delay; throughput is what you actually get. Enter a file size and a link speed and the calculator applies your chosen protocol overhead — none for raw theoretical bandwidth, about 4 percent for TCP/IP headers and acknowledgements, or about 6 percent for TCP plus HTTP — then factors in MTU-driven per-packet header cost using your configured MTU, which defaults to the standard Ethernet value of 1,500 bytes.
Latency enters because a single TCP flow cannot exceed window_size / RTT in throughput regardless of how much bandwidth is available. This is the bandwidth-delay product, and it is why a 1 Gbps link with a 150 ms RTT delivers only a few tens of megabits per second on one connection unless window scaling is generous. The tool reports how much of your total transfer time is attributable to latency rather than bandwidth, which tells you immediately whether to buy more capacity or to move the data closer. To size the window itself, use the TCP window size calculator.
Divide the path distance by the propagation speed of the medium, double it for a round trip, then multiply by a real-world factor for routing and equipment delay. Over fibre, the shortcut is about 10 ms of round-trip latency per 1,000 km of great-circle distance before overhead.
Roughly 5 microseconds per kilometre one way, or 5 ms per 1,000 km, because light travels at about 200,000 km/s in glass rather than 300,000 km/s in vacuum. Round trip, double it.
Yes, as an upper bound. The ping tab converts a measured RTT into a maximum plausible distance and draws it as a radius on a map. Because real routes are indirect, the true distance is always less than the theoretical maximum — a ping tells you a host cannot be farther than X, never that it is exactly X away.
Indirect cable routing, router and switch processing, queuing during congestion, last-mile access technology, and any middleboxes in the path. Raise the multiplier toward 2.5× or 3.0× to model those conditions. Consistent large gaps usually mean your traffic is being routed somewhere unexpected — a traceroute will show where.
Under 20 ms is excellent and typical of same-metro or regional traffic. 20–50 ms is good for most applications including video calls. 50–100 ms is normal for intercontinental traffic and fine for web browsing. Above 150 ms, interactive applications and competitive gaming feel noticeably degraded.
A geostationary satellite orbits at about 35,786 km. Even at the vacuum speed of light, one hop up and back is roughly 240 ms, so a round trip approaches half a second before any equipment delay. Low-earth-orbit constellations sit around 550 km and cut that to tens of milliseconds. Select the satellite medium to model the vacuum propagation speed; add the orbital path length yourself for a full GEO estimate.
No. Bandwidth and latency are independent. More bandwidth moves more data per second once transmission starts; it does not shorten the physical path or reduce the delay before the first byte arrives. The only ways to reduce latency are a shorter or more direct path, fewer hops, or less queuing.
Yes. Every input is encoded in the URL, so the shareable link button produces a link that reopens the tool with your exact scenario loaded. For related network planning, see the subnet calculator and the DNS lookup tool.
Latency is distance divided by the propagation speed of the medium. In fiber, light travels about 200,000 km/s, which is roughly 5 ms of one-way latency per 1,000 km. Round-trip time is double that, and real-world latency adds router and queuing delay on top.
The propagation figure is a physics floor. Actual paths are not straight lines, and every router, switch, and congested link adds processing, serialization, and queuing delay. A multiplier of about 2x the theoretical minimum is a common real-world estimate.
No. Bandwidth is how much data fits through the pipe per second; latency is how long a single bit takes to cross it. They are independent, which is why upgrading from 100 Mbps to 1 Gbps does not make a distant server respond faster.
A geostationary satellite orbits about 36,000 km above Earth. Even at the speed of light, the signal up to the satellite and back down adds roughly 480 to 600 ms of round-trip delay, independent of how much bandwidth the link offers.