GPS Speed Without a Speed Sensor: the Haversine Fallback

navigator.geolocation.watchPosition is supposed to hand back a speed field in meters per second — but on plenty of devices and browsers it comes back null, especially at low velocity or with a weak fix. The GPS Speedometer doesn't just show a blank number when that happens; it derives speed itself from consecutive position fixes.

The math: Haversine distance over elapsed time

Given two GPS fixes with a timestamp each, the tool computes the great-circle distance between their latitude/longitude pairs using the Haversine formula, then divides by the elapsed time to get a derived speed. It's the same approach a running watch uses when GPS speed reporting is unreliable — position-over-time is more robust than trusting a single instantaneous speed field that may or may not be populated.

Why low-accuracy fixes get thrown out

Every GPS fix carries an accuracy radius in meters. When that radius exceeds 50m — common indoors, under tree cover, or between tall buildings — the tool reports "waiting for a better GPS fix" and holds off on computing speed at all, rather than showing a number derived from a fix that could be 50+ meters off. A bad fix used naively can produce a wildly wrong instantaneous speed; discarding it is the more honest choice than smoothing over garbage input.

What it's for

Cross-checking a car's speedometer on a straight road, timing a run or bike ride, or just satisfying curiosity about how fast you're actually moving — all using enableHighAccuracy: true for the best fix your device can produce. It is not a substitute for a vehicle's certified speedometer in any context with legal consequences. For heading instead of speed, the Digital Compass reads the magnetometer; for what a trip actually costs once you know the distance, see the Fuel Cost & Trip Calculator.