Haversine distance - great-circle km, mi and m between two points
Get the great-circle distance between two GPS points in kilometres, miles and metres at once: from 40.7128, -74.006 to 51.5074, -0.1278 it is 5570.22218 km, measured on a sphere of radius 6371 km. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Lat1
- 40.7128
- Lng1
- -74.006
- Lat2
- 51.5074
- Lng2
- -0.1278
- Km
- 5,570.22218
- Mi
- 3,461.175597
- M
- 5,570,222.18
When you need the shortest path over the Earth's surface between two GPS coordinates, planar math and simple Euclidean distance are wrong: they ignore curvature and produce large errors on city-to-city and country-to-country hops. The haversine formula treats the planet as a sphere of fixed radius and returns the great-circle arc length—the standard first-pass distance used in logistics, store-locator APIs, fleet routing prefilters, and geospatial analytics.
What the haversine formula actually computes
The haversine formula is a numerically stable way to evaluate the central angle between two points on a sphere from their latitudes and longitudes, then multiply that angle by the sphere's radius to get arc length. In plain terms: given point A and point B, it answers how far you would travel if you followed the shortest path on a smooth globe rather than a flat map.
This capability uses the conventional mean Earth radius of 6371 kilometres, which is the value most open-source GIS snippets, PostGIS-style tutorials, and mobile SDKs document for haversine. It does not use an ellipsoidal model such as Vincenty or Karney on WGS84, so results can differ by a small fraction of a percent from geodesic libraries that model polar flattening—usually fine for store radius checks, delivery ETA bands, and analytics buckets, and not a substitute for survey-grade surveying.
Output is always three units: kilometres (km), international statute miles (mi, using 1609.344 metres per mile), and metres (m).
Input contract, coordinate ranges, and common mistakes
Send four numbers: lat1 and lng1 for the origin, lat2 and lng2 for the destination, all in decimal degrees. Latitude must lie in the closed interval from −90 to 90; longitude must lie in −180 to 180 inclusive. Missing fields, non-finite values, or strings that do not parse as numbers also fail validation before any distance is computed.
Identical points correctly return zero distance. Antipodal pairs are supported; internal clamping keeps floating-point edge cases from producing NaN.
Where great-circle distance fits in a product pipeline
Use haversine as a cheap, auditable distance primitive inside checkout radius gates, nearest-warehouse selection, fraud signals that compare billing city to device GPS, sports-app activity summaries, and bulk CSV enrichment jobs that need km or miles next to every origin–destination pair. Pair it with a geocoder only when you start from addresses; once you already have lat/lng, avoid re-geocoding just to get distance. For multi-stop routing, road travel time, or turn-by-turn paths, keep a dedicated routing engine—haversine is as-the-crow-flies, not drive distance.
For legal property boundaries or cadastral work, use ellipsoidal geodesics and local CRS.
What you can do with it
Store-locator and delivery radius checks
Compare a shopper's GPS pin to each store or dark-store coordinate and keep only locations within N kilometres or miles before ranking by inventory or ETA.
Logistics and warehouse prefilter
In a fleet or multi-warehouse system, drop candidate hubs outside a great-circle threshold so expensive road-routing calls only run on the shortlist.
FAQ
What is the haversine distance formula?
It is a spherical trigonometry formula that converts two latitudes and longitudes into the central angle between them, then multiplies by Earth's radius (here 6371 km) to get great-circle arc length.
What coordinate ranges are accepted?
Latitude must be between −90 and 90 inclusive; longitude must be between −180 and 180 inclusive.
Is this the same as driving distance?
No. Haversine is as-the-crow-flies on a sphere. Road distance, traffic, and elevation require a routing engine; use this for radius filters and straight-line estimates.
Why is my distance wrong even though the tool accepted the coordinates?
The most common cause is swapping latitude and longitude: both numbers can still fall inside the allowed ranges, so nothing is rejected, but the points move. Another is entering projected grid metres instead of decimal degrees, which the tool does not expect.
How close is haversine to an ellipsoid-based distance?
Usually within a small fraction of a percent. Haversine treats the Earth as a sphere and ignores polar flattening, which is fine for store radius checks, delivery bands and analytics, but not for survey-grade or property-boundary work.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/geo/haversine \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"lat1":40.7128,"lng1":-74.006,"lat2":51.5074,"lng2":-0.1278}'const res = await fetch("https://api.kit.forhosting.com/geo/haversine", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"lat1": 40.7128,
"lng1": -74.006,
"lat2": 51.5074,
"lng2": -0.1278
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/geo/haversine",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"lat1": 40.7128,
"lng1": -74.006,
"lat2": 51.5074,
"lng2": -0.1278
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/geo/haversine", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"lat1":40.7128,"lng1":-74.006,"lat2":51.5074,"lng2":-0.1278}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"lat1":40.7128,"lng1":-74.006,"lat2":51.5074,"lng2":-0.1278}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/geo/haversine", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"lat1": 40.7128,
"lng1": -74.006,
"lat2": 51.5074,
"lng2": -0.1278
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "geo.haversine",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This endpoint accepts two latitude/longitude pairs, validates their ranges, and returns the distance in kilometres, statute miles, and metres in one deterministic call, with no maps tiles, no third-party geocoding, and no hidden network hop.
What the haversine formula actually computes
The same inputs always produce the same JSON, because the implementation is pure arithmetic with fixed rounding—no clocks, no random seeds, and no remote tile or geocoding service in the path.
Input contract, coordinate ranges, and common mistakes
Values outside those ranges are rejected with invalid_input and are never charged. A frequent client bug is swapping latitude and longitude (for example pasting city centres as lng,lat from a GeoJSON-ish habit): the call may succeed if both numbers still fall inside both ranges, but the distance will be nonsense for your intended cities—always double-check that lat is north-south and lng is east-west. Another pitfall is feeding projected coordinates or local grid metres instead of WGS84-style decimal degrees; this API expects geographic degrees only. Pricing is a flat $0.002 per successful item on the API; the in-browser tool path for tier-A parse capabilities is designed so you can experiment without wiring a full pipeline first.
Where great-circle distance fits in a product pipeline
Call it from a Worker, a backend job, or a script: pass the four coordinates, read km/mi/m from the JSON result, and store or display them. For everything between—dashboards, SLAs, and API filters—this endpoint is the small, deterministic building block: validate ranges, measure the great circle, return three units, done.
Integration use cases
Bulk CSV enrichment of origin–destination pairs
Add km, mi, and m columns to shipment, telemetry, or event exports without spinning up a GIS stack or calling a maps billing API.
Technical questions
Which units does geo.haversine return?
Every successful response includes km (kilometres), mi (international statute miles), and m (metres), plus the radius_km constant used for the calculation.
How much does the API cost?
Each successful request is priced at $0.002 from your prepaid ForHosting KIT balance. Failed validation is not charged. No subscription is required.