DMS to Decimal Degrees: Converting GPS, Aviation, and Nautical Coordinates
DMS to decimal degrees conversion is the bridge between cockpit paperwork and digital navigation. Every ICAO flight plan, NOTAM bulletin, and nautical chart publishes coordinates in degrees-minutes-seconds — but the moment you need to plot a route in ForeFlight, enter a waypoint into a Garmin G1000, or calculate great-circle distance with the Haversine formula, you need plain decimal numbers. This guide walks through the conversion formula, then focuses on where it matters most: aviation, maritime navigation, and GPS field work.

The DMS to Decimal Degrees Formula
One line does all the work:
Decimal Degrees = D + (M ÷ 60) + (S ÷ 3600)
Why those divisors? One degree contains 60 arc-minutes, and one arc-minute contains 60 arc-seconds, so a full degree holds 3,600 arc-seconds. Dividing minutes by 60 and seconds by 3,600 converts each component back into fractional degrees. After computing the unsigned result, apply the hemisphere sign: North and East stay positive; South and West go negative.
The formula is identical whether you're converting a waypoint from an FAA airport diagram or a position fix from a sextant. If you later need the result in radians for trig functions, our degrees to radians converter handles that step.
Where DMS Shows Up: GPS Receivers, Flight Plans, and NOTAMs
Despite decimal degrees dominating software, DMS refuses to die — for good reason. Pilots read coordinates aloud over radio, and three distinct numbers (degrees, minutes, seconds) are less error-prone than a single long decimal. Here's where you'll encounter DMS in the wild:
- ICAO flight plans (Item 15 & 18)— Waypoints defined by geographic coordinates use the compressed format 4038N07346W (40°38′N, 073°46′W). Seconds are often omitted because en-route waypoints don't need sub-nautical-mile precision.
- NOTAMs (Notices to Air Missions)— Temporary flight restrictions, airspace closures, and obstacle alerts all reference DMS coordinates. A typical NOTAM circle might read "centered at 334521N1181523W with a 3 NM radius."
- ADS-B transponder data— Aircraft broadcast their position in a binary format that, when decoded by services like FlightAware or ADS-B Exchange, appears as DMS or decimal depending on the viewer. Raw CPR (Compact Position Reporting) encoding uses a latitude/longitude grid that ultimately resolves to decimal degrees.
- Nautical charts and passage planning — The NOAA Office of Coast Survey publishes charts with DMS graticules. When a sailor plots a waypoint from chart to GPS, they read DMS off the chart margin and convert to whatever format the chartplotter expects.
- Handheld GPS receivers— Garmin eTrex, GPSMAP, and similar units let you toggle between DMS, DDM, and decimal. Search-and-rescue teams typically communicate in DMS because it matches topographic map grids.
FAA and ICAO Coordinate Formats for Airports
Every airport in the world has an official Aerodrome Reference Point (ARP) published in DMS. The FAA's aeronautical data portal lists U.S. airports to the hundredth of an arc-second. ICAO's Annex 15 (Aeronautical Information Services) mandates DMS for all published aerodrome coordinates worldwide.
The FAA compresses coordinates into a string like 40-38-23.0000N with hyphens separating the components. ICAO flight-plan format drops all separators: 4038N07346Wuses 4 digits for latitude (DDMM) and 5 for longitude (DDDMM) when seconds aren't included, or 6 and 7 digits respectively (DDMMSS / DDDMMSS) when they are. Getting the digit count wrong is one of the most common data-entry errors in flight dispatch.
Converting Real Airport Coordinates: JFK, Heathrow, and Narita
Let's convert three major airports step by step.
JFK International (40°38′23″N, 73°46′44″W):
- Latitude: 40 + (38 ÷ 60) + (23 ÷ 3600) = 40 + 0.63333 + 0.00639 = 40.6397°
- Longitude: 73 + (46 ÷ 60) + (44 ÷ 3600) = 73 + 0.76667 + 0.01222 = −73.7789° (W = negative)
London Heathrow (51°28′39″N, 0°27′41″W):
- Latitude: 51 + (28 ÷ 60) + (39 ÷ 3600) = 51 + 0.46667 + 0.01083 = 51.4775°
- Longitude: 0 + (27 ÷ 60) + (41 ÷ 3600) = 0 + 0.45 + 0.01139 = −0.4614° (W = negative)
Tokyo Narita (35°45′53″N, 140°23′11″E):
- Latitude: 35 + (45 ÷ 60) + (53 ÷ 3600) = 35 + 0.75 + 0.01472 = 35.7647°
- Longitude: 140 + (23 ÷ 60) + (11 ÷ 3600) = 140 + 0.38333 + 0.00306 = 140.3864° (E = positive)
Punch those decimal pairs into Google Maps or Mapbox and you'll land right on the airfield. Dispatchers do this conversion daily when programming FMS (Flight Management System) waypoints for routes that pass through uncontrolled airspace where named fixes don't exist.
The Haversine Formula: Why It Needs Decimal Degrees
The Haversine formula calculates great-circle distance between two points on a sphere. It's the standard in aviation for estimating flight distances and in maritime navigation for passage planning. But it won't accept DMS directly — it needs decimal degrees, which then get converted to radians internally.
Here's the core equation:
a = sin²(Δφ/2) + cos(φ1) · cos(φ2) · sin²(Δλ/2)
Where φ is latitude and λ is longitude in radians. So the pipeline runs: DMS → decimal degrees → radians → Haversine. Skipping the first step and trying to feed DMS components directly into sine and cosine functions produces garbage — you'd be treating 40 degrees and 38 minutes as separate angular inputs rather than parts of a single angle. Every mapping API (Google Maps Distance Matrix, Mapbox Directions, OpenRouteService) follows this same pipeline under the hood.
What One Arc-Second Means at Different Latitudes
Arc-second precision isn't constant across the globe. Latitude arc-seconds stay roughly the same everywhere (~30.87 m), but longitude arc-seconds shrink as you move toward the poles because meridians converge. Here's the real-world impact:
| Latitude | 1″ Latitude | 1″ Longitude | Example Location |
|---|---|---|---|
| 0° (equator) | 30.87 m | 30.87 m | Quito, Singapore |
| 30° | 30.87 m | 26.73 m | Cairo, Houston |
| 45° | 30.87 m | 21.83 m | Ottawa, Milan |
| 60° | 30.87 m | 15.43 m | Helsinki, Anchorage |
| 80° | 30.87 m | 5.36 m | Svalbard, Arctic |
For aviation, this matters during precision approaches. A one-arc-second error at JFK (latitude 40°) displaces you about 30.9 m in the north-south direction but only 23.6 m east-west. For a Category III ILS approach with a 60-meter-wide runway, that error could mean touching down off-center. ADS-B position reports carry enough bits to resolve roughly 5.1 meters — well within whole-second precision but far better than what a flight plan's rounded DMS provides.
Negative Values and Hemisphere Conventions
Two conventions coexist, and mixing them up is a classic dispatch error.
Letter convention (DMS default):append N, S, E, or W after the coordinate. 33°56′33″S, 151°10′38″E (Sydney Airport). There's no ambiguity — the letter tells you the hemisphere explicitly. Aviation radio communications exclusively use this format because hearing "three-three degrees five-six minutes south" is unambiguous even through static.
Signed convention (decimal default):positive for N/E, negative for S/W. Sydney becomes −33.9425°, 151.1772°. Software prefers signed numbers because comparison operators, sorting, and arithmetic just work without special-case hemisphere logic. The decimal to DMS converter handles the reverse conversion and automatically detects the hemisphere from the sign.
The trap? A coordinate like 73.7789°W is sometimes entered as 73.7789 (forgetting the negative) and sometimes as −73.7789. If the receiving system expects a signed number and gets a positive West longitude, it places the point in the eastern hemisphere — mirrored across the Prime Meridian. In 2006, a GPS-guided cargo ship ran aground near the Aleutian Islands partly because of a sign error in a transferred waypoint. Always double-check which convention your target system expects.
Common Parsing Mistakes in Coordinate Strings
Coordinate strings are notoriously inconsistent. Whether you're scraping NOTAM data, importing waypoints from a pilot's kneeboard app, or bulk-converting coordinates from maritime logbooks, these parsing errors surface repeatedly:
- Dividing seconds by 60 instead of 3,600. This is the most common math error. Seconds are fractions of a degree, not a minute. Dividing 44 seconds by 60 gives 0.7333 when the correct value (44 ÷ 3600) is 0.01222. The error inflates your longitude by ~81 km at the equator — enough to place JFK in central New Jersey.
- Misreading compressed ICAO format.The string 4038N07346W encodes 40°38′N, 073°46′W — but some parsers read it as 40°3′8″N because they split the digits wrong. Remember: latitude is DDMM (or DDMMSS), longitude is DDDMM (or DDDMMSS). Longitude always gets an extra digit because it ranges to 180°.
- Treating the degree symbol as a period.Some OCR software and PDF scrapers misread ° as a decimal point, turning 40°38 into 40.38 — which is 40 degrees 22 minutes 48 seconds, not 40 degrees 38 minutes. Always validate that minutes fall between 0 and 59.
- Swapping lat/lon order.DMS tradition puts latitude first: 40°38′N, 73°46′W. But GeoJSON and many database schemas use [longitude, latitude]. If you see a "latitude" value above 90, it's almost certainly a swapped longitude — latitude maxes out at 90°.
- Ignoring leading zeros on longitude.ICAO format pads longitude to three digits: 007°27′W for Heathrow, not 7°. Stripping the leading zero before parsing can shift digit boundaries in compressed strings, producing completely wrong coordinates.
When building parsers for coordinate data, validate every extracted value: degrees ≤ 90 (lat) or ≤ 180 (lon), minutes < 60, seconds < 60. If any value exceeds these limits, the parse is wrong. For radian-based calculations downstream, you can pipe the validated decimal result through our radians and degrees converter to cross-check the angular value.
