Coordinates are a compact description of a place, but a small input mistake can move the point far away. The distance calculator takes decimal latitude first and decimal longitude second for each endpoint. It validates their ranges but cannot know whether a valid-looking coordinate is the location you intended. This guide provides a practical input check, including sign conventions, decimal format and the difference between plausible numbers and a verified place.
Reference table
| Item or scenario | Value or choice | What to remember |
|---|---|---|
| Latitude range | −90 to 90 | North positive / south negative |
| Longitude range | −180 to 180 | East positive / west negative |
| 10°30′ south | −10.5 | Decimal-degree latitude |
| Swapped valid numbers | May pass validation | Check labels, not only ranges |
Know the two coordinate ranges
Latitude runs from −90 to 90 degrees and describes north-south position. Positive is north; negative is south. Longitude runs from −180 to 180 and describes east-west position. Positive is east; negative is west. The tool rejects values outside those ranges. A swapped pair can sometimes remain inside both ranges, so range validation alone is insufficient. A latitude of 2 and longitude of 49 are numerically valid, but they do not describe the same point as latitude 49 and longitude 2. Confirm the labels in the coordinate source before pasting.
Use decimal degrees in the fields
Some sources display degrees, minutes and seconds instead of decimal degrees. The input fields do not parse that notation. To convert, add degrees plus minutes divided by sixty plus seconds divided by 3,600, then apply the hemisphere sign. A west or south coordinate is negative as a whole; do not make only the minutes negative. Retain enough precision for the endpoint scale you need. The examples on this site use rounded city-center coordinates and should not be treated as precise navigation points or property locations.
For the next input check, use Straight-Line Distance Calculator. Its result should retain the assumptions described here.
Check signs before comparing distance
For a place west of the reference meridian, a missing negative longitude sign moves it to an eastern longitude. For a place south of the equator, a missing negative latitude does the same northward. These mistakes often produce a valid coordinate and a plausible-looking distance, which makes them harder to notice than an input error. Check the hemisphere or the source's signed notation. Do not infer the sign from a city name alone if you are unfamiliar with its geography. The coordinate source should make the relationship clear.
Test identical and nearby points
Entering the same verified endpoint twice should produce zero distance. This checks that you have copied the pair consistently, though it does not prove the place is correct. A second check with two nearby verified points should give a scale consistent with their rough separation. If the output seems unexpectedly large, review order, sign and decimal position before changing the model. A small test is preferable to interpreting a long-distance result whose endpoints you have not verified. Save the labels alongside the numbers so the input remains understandable later.
A related planning question is covered in Kilometers and miles: comparing travel distances consistently.
A coordinate checklist before sharing a result
Build a four-part note for each endpoint: place label, latitude, longitude and where you obtained the pair. Read the numbers against the source one field at a time. If the source uses a comma as a decimal separator, convert it to a decimal point for these numeric inputs rather than pasting a mixed notation. Remove hemisphere letters only after applying the correct sign. A copied pair can be internally consistent and still refer to a city center when you needed a terminal, so check the place label too. After calculating, retain the coordinate note with the output. This allows someone else to reproduce your result without trying to infer which point a city name meant. The tool's valid-range checks are useful but limited: they cannot detect a one-digit transcription error that remains in range. A small input verification routine prevents much more confusion than interpreting a surprising result after the coordinates have been separated from their provenance.
Worked example
Worked example: Paris's illustrative central pair is latitude 48.8566 and longitude 2.3522. Entering 2.3522 as latitude and 48.8566 as longitude remains valid but describes a different point. London's illustrative longitude is −0.1278, so removing the minus sign changes its east-west location. For a degrees-minutes-seconds illustration, 10 degrees 30 minutes south becomes −10.5 decimal degrees. Use −10.5 in the latitude field, not the string 10°30′S. Each example illustrates notation, not a navigation recommendation. Once both pairs are verified, run the distance calculation and keep endpoint names in your private notes.
Before you finish
- Confirm the source lists latitude before longitude.
- Convert degrees-minutes-seconds to decimal degrees if needed.
- Apply the hemisphere sign to the entire coordinate.
- Test an identical pair for zero distance.
- Keep endpoint names and coordinate provenance with the result.
Your next step
Numeric validation is the first check, geographic verification is the second. The tool can perform the former and relies on you for the latter. See the great-circle guide before treating the resulting kilometers as a journey length, because correct coordinates still do not supply a road or transport route.
Continue with Checking the geographic spread of a multi-stop itinerary. When your plan needs the next calculation, open Itinerary Pace Calculator and carry over only the inputs appropriate to that tool.