Degrees, Minutes and Seconds to Decimal Degrees: What Converts, What Refuses, and What Goes Wrong Quietly

The coordinate-converter reads degrees-minutes-seconds, degrees and minutes with no seconds, and decimal minutes — provided the hemisphere letter is there on both sides. Below is the measured matrix: every form we typed, whether it parsed, and what came back.

Read the target first. Target projection (CRS) ships on SIRGAS 2000 / UTM 23S (EPSG:31983), which is projected: on that default, 23°33'S 46°38'W comes back as 333283.881280 and 7394643.649020 under the labels X (Easting) and Y (Northing) — metres — and the DMS box beside it reads DMS not available for a projected CRS. Three clauses get you degrees: leave Source projection (CRS) on WGS 84 (EPSG:4326), set the target to SIRGAS 2000 (EPSG:4674), and do not make the target equal to the source, which prints Choose a different target projection to see the conversion. instead of a number. The EPSG cheat sheet has the other codes worth putting there.

Measured on 23 September 2026 against static-page-tools@79fc1f6, the deployed tree, with GDAL 3.13.3 "Iowa City" for the command-line transcripts.

What parses, and what it gives back

Nine forms typed into the DMS (Degrees / Minutes / Seconds) field, a fresh page each, source WGS 84 (EPSG:4326) and target SIRGAS 2000 (EPSG:4674):

• Full degrees-minutes-seconds — 23°32'56.10"S 46°38'20.30"W parses: -23.54891667 and -46.63897222. It is the field's own placeholder, e.g. 23°32'56.10"S 46°38'20.30"W.
• Degrees and minutes, no seconds — 23°33'S 46°38'W parses: -23.55000000 and -46.63333333. This is the news — the same string was refused last week.
• Decimal minutes — 23°33.5'S 46°38.2'W parses: -23.55833333 and -46.63666667. Also new, which is not what the comment above the code says.
• Space-separated, no symbols — 23 32 56.1 S 46 38 20.3 W parses: -23.54891667 and -46.63897222, the same pair as the first bullet.
• Lowercase hemisphere letters — 23°33's 46°38'w parses: -23.55000000 and -46.63333333.
• The letters swapped — 23°32'56.10"N 46°38'20.30"E parses: 23.54891667 and 46.63897222, with no error and no warning.
• No hemisphere letters at all — 23°32'56.10" 46°38'20.30" is refused: DMS format not recognized.
• A latitude out of range — 95°00'00"S 46°38'00"W is refused: DMS format not recognized.
• Decimal degrees typed into the DMS box — -23.5489 -46.6388 is refused: DMS format not recognized.

Three of the nine are refused, for three different reasons behind one message. 23°32'56.10" 46°38'20.30" never matches the pattern: the hemisphere letter carries the sign and there is no default. -23.5489 -46.6388 does not match either — it is a decimal pair, and the decimal-degrees field above is where it belongs. 95°00'00"S 46°38'00"W is the odd one: it matches the pattern perfectly and is thrown out afterwards by the range check, because ninety-five is not a latitude.

One form parses and is still wrong. 23°32'56.10"N 46°38'20.30"E is the first bullet with both letters flipped, and it returns 23.54891667 and 46.63897222 — a point in the Arabian Sea off Somalia rather than São Paulo — silently. Accepted and correct are different verdicts, and nothing here can tell a deliberate N from a typed one.

One display quirk. The result half re-prints the coordinate as DMS and rounds the seconds without carrying them, so 23°33'S 46°38'W echoes back as 23°33'0.00"S 46°37'60.00"W. The point is right — 46°37'60" is 46°38'00" — and the decimals beside it read -23.55000000 and -46.63333333, but the string is malformed. Read the decimals, not the echo.

Why the seconds were required, and what the fix really unlocked

They were required, and we said so: our CSV guide told readers the converter wanted seconds, and it did. 23°33'S 46°38'W returned nothing at all. If you hit that message and now see the same string accepted, you are not going mad — it changed.

What changed is larger than it sounds. The old pattern demanded three numeric groups on each side — degrees, minutes and seconds — so any two-group form was rejected whatever was in it. Checked out and run beside today's build on the same inputs: 23°33'S 46°38'W gave nothing before and gives -23.55000000 now; 23°33.5'S 46°38.2'W gave nothing before and gives -23.55833333 now. The decimal was never the problem. 23°33.5'00"S 46°38.2'00"W — decimal minutes with a seconds group — parsed before the change and parses now; it was the missing third group doing the rejecting. So the fix unlocked every two-group form, decimal minutes included.

Two things it did not do. It did not add lowercase hemisphere letters: 23°33'00"s 46°38'00"w parsed before the change too, and 23°33's 46°38'w is new only because it has two groups. And it did not relax the letters themselves, still required on both sides.

Converting a whole column in a spreadsheet

For a column of them, one formula does degrees-plus-minutes and negates S and W. With the cell in A1, on a Calc or Sheets locale that separates arguments with ; (Excel in English wants ,):

=IF(OR(RIGHT(A1;1)="S";RIGHT(A1;1)="W");-1;1)*(VALUE(LEFT(A1;FIND("°";A1)-1))+VALUE(MID(A1;FIND("°";A1)+1;FIND("'";A1)-FIND("°";A1)-1))/60)

The formula gives -23.55 for 23°33'S, -15.78333 for 15°47'S, -46.63333 for 46°38'W, 10.25 for 10°15'N and 10.25 for 10°15'E — the sign branch runs both ways. It gives -23.55833 for 23°33.5'S, exact, on a locale whose decimal separator is the point; on a comma-decimal locale the 33.5 inside the cell is the first thing to check.

Know its domain, because the way it fails is the dangerous part. It handles degrees plus minutes with a trailing hemisphere letter, and nothing else. A cell with seconds is not refused, it is silently truncated: 23°32'56.10"S gives -23.53333 where the true value is -23.548917, a point about 1.7 km away, with no error in the cell. A cell with no hemisphere letter is not refused either: 23°33' gives 23.55, positive, northern hemisphere. It does refuse 23°S, 23 33 S and -23.55, each with #VALUE! — and those are the harmless failures. The two silent ones are what reaches a map.

On the command line, GDAL has no DMS parser on the CSV path

On this path, GDAL 3.13.3 does not read a degree sign. ogrinfo -oo AUTODETECT_TYPE=YES -al -so on a three-row all-DMS file types both coordinate columns as text — lat: String (0.0) and lon: String (0.0) — where the same call on the decimal version of that file types them Real (0.0).

The conversion then succeeds and produces nothing. ogr2ogr -f GeoJSON out.geojson dms.csv -oo X_POSSIBLE_NAMES=lon -oo Y_POSSIBLE_NAMES=lat exits 0, prints one line — Warning 1: Invalid value type found in record 1 for field lat. This warning will no longer be emitted — and writes "geometry":null for all three rows, with lat and lon dropped from the properties too, having been consumed as geometry fields. A file that converted, with no points in it. The record number is the first failing row rather than always 1: put a numeric row first and a DMS row second and the same command says record 2.

The control is what makes that readable. The same command with the same flags, on the decimal version of the file, writes three real points — "coordinates":[-46.63,-23.55] for the first — and no warning at all. So "geometry":null is GDAL refusing the cell, not the command being wrong. Adding -oo AUTODETECT_TYPE=YES to the ogr2ogr call changes neither outcome.

In the csv-viewer, it depends on the rest of the file

Drop a CSV with a 23°33'S cell into the csv-viewer and what you get depends on whether anything else survived. One DMS row among two good ones: the layer opens, the two good points draw, and the counts line reads 2 points · 1 row without valid coordinates. A file in which every row is DMS: no layer, no counts line, no Export button at all, only the banner No valid coordinate columns found. Check that the selected columns contain numeric latitude and longitude values.. The control — the same three rows in decimal degrees — reads 3 points, with no skip clause after it. Either way the picker still opens and still pre-selects lat and lon; the refusal comes after you click Open on map.

Test files you can use

Nothing to download — three rows each, typed. Copy a bullet into a text editor, one span per line, save as .csv, drop it into the csv-viewer; for the converter, paste a string from the matrix above into the DMS field. The second file is the third with row 2's coordinate cells rewritten in degrees and minutes.

• Every row in degrees and minutes — id,lat,lon,nome · 1,23°33'S,46°38'W,São Paulo · 2,15°47'S,47°53'W,Brasília · 3,3°07'S,60°01'W,Manaus — the banner, and the GDAL transcripts above.
• One DMS row among two good ones — id,lat,lon,nome · 1,-23.55,-46.63,São Paulo · 2,15°47'S,47°53'W,Brasília · 3,-3.12,-60.02,Manaus — the skip counter.
• Control — id,lat,lon,nome · 1,-23.55,-46.63,São Paulo · 2,-15.79,-47.88,Brasília · 3,-3.12,-60.02,Manaus — 3 points, nothing skipped.

For teams

A converted coordinate is still just a coordinate. These strings came from a GPS screen, a survey sheet or somebody's handwriting, and they are going to a point a person has to visit, photograph, fill in and sign off. Geodocs takes the file, keeps every column as a field the team fills in from the phone, runs the review, and puts the map into the report. Convert here; do the work there.