UTM to latitude and longitude: the zone, the hemisphere, and the point 611 km away
Short answer: an easting and a northing are metres measured inside one 6°-wide zone, so without the zone number and the hemisphere letter they are not a location. Give the coordinate converter both and the point lands on itself; change the zone by one and it slides 611,563 m — 611.563 km — due east or west along the same parallel; drop the 10,000,000 m false northing and the same metres land 9,981,808 m away, on the Antarctic coast. Below: the three errors, the case where the converter itself is wrong today, and the export that now refuses to hand your easting back as a longitude.
Every number below was measured on 23 September 2026 with GDAL 3.13.3, PROJ 9.8.1 and the two browser tools at static-page-tools@79fc1f6 — except the two projection constants in the next section, which are definitions rather than readings, and the export refusal further down, which landed after that commit. The reference point is São Paulo, -46.6388 -23.5489 in SIRGAS 2000, whose UTM 23S metres are 332724.396065356 7394759.09232324: gdaltransform converts one into the other and back without moving a printed digit, so every distance below is the error and nothing else.
What a UTM pair leaves out
UTM cuts the world into sixty zones 6° of longitude wide and measures metres inside each one. Two constants keep those metres positive, and both are parameters of the projection rather than anything this post measured: the central meridian of each zone gets a false easting of 500,000 m, and zones south of the equator add a false northing of 10,000,000 m, which northern zones do not. The false easting is also where the range you should expect comes from, and it is arithmetic you can do yourself — a zone reaches 3° either side of its central meridian, and 3° of longitude is about 334 km at the equator and less the further you are from it, so an easting inside its own zone sits within roughly 334 km of the 500,000 m centre line: between about 166,000 and 834,000 at the widest. So 332724.396065356 7394759.09232324 is a complete answer only once you also say 23 and S — the same two numbers are a valid point in each of the sixty zones and in both hemispheres, and nothing in the file or the spreadsheet cell says which. The converter's UTM card asks for all three: Zone, Easting (E) and Northing (N).
Error one: the wrong zone
With Source projection (CRS) on SIRGAS 2000 (EPSG:4674) and Target projection (CRS) on WGS 84 (EPSG:4326) the Zone box decides, and the same metres under three zones give three answers: 22S returns -23.54890000 -52.63880000, 23S returns -23.54890000 -46.63880000, 24S returns -23.54890000 -40.63880000. The latitude does not move at all. The longitude moves exactly 6° per zone — one zone width — which at São Paulo's latitude is 611,563 m measured on a sphere, or 612,575 m on the GRS80 ellipsoid; every distance in this post is the spherical one unless it says otherwise. gdaltransform -s_srs EPSG:31982 -t_srs EPSG:4674 and its EPSG:31983 and EPSG:31984 neighbours print the same three pairs, to the digit.
No message is involved — the helper line under the UTM card stays empty for all three — and a wrong zone does not scatter your data, it slides it sideways onto a plausible parallel, which is why nobody catches it on the map.
Error two: the hemisphere the Zone box cannot say
Here the tool is wrong, and you should know that before you trust it. The Zone box takes a letter, but for zone numbers 17 to 25 the letter is discarded: 23N and 23n both return -23.54890000 -46.63880000, the 23S answer, byte for byte, with an empty helper line, and the read-only result echoes 23S back at you. Outside that band the letter works — 16N and 16S differ, and so do 26N and 26S. Zones 17 to 25 are exactly Brazil.
That costs a real point. Boa Vista, in Roraima, sits at -60.6714 2.8235, north of the equator, in zone 20N; gdaltransform -s_srs EPSG:4674 -t_srs EPSG:31974 gives its metres as 758873.827731744 312343.360559676. Typed into the converter with that correct zone 20N, the answer is -86.38145844 -23.14479495 — 400 km from the South Pole, 10,002,260 m (10,002.3 km) from Boa Vista, with no message of any kind. 20S returns the identical pair, which proves it is the letter being dropped and not the arithmetic, and GDAL reproduces the same misreading to eight decimals when handed EPSG:31980, zone 20S, on purpose. The picker cannot rescue you: its Brasil group is entirely southern, and the only four northern UTM entries in the whole list are European and North American. Until that is fixed, a Brazilian coordinate north of the equator has to be converted on the command line, and gdalsrsinfo -o wkt1 EPSG:31974 prints PROJCS["SIRGAS 2000 / UTM zone 20N" so you can check the code before you trust it.
The same error arrives a second way, in files rather than in a picker: a southern northing that lost its false northing. Enter -2605240.90767676 — São Paulo's northing minus 10,000,000 — with zone 23S and the answer is -66.58959006 138.77474853, the Antarctic coast south of Australia, 9,981,808 m (9,981.8 km) away, empty helper line again. The page's own auto-zone readout relabels the point 54S, and that readout, not an error message, is the most legible tell you get.
Error three: no zone at all, and a zone it cannot read
Two different states, and the tool says two different things. Leave the Zone box empty and the helper line reads Fill zone, easting and northing to convert., a prompt with no field marked red: the conversion has not been attempted. Type something it cannot parse and you get Invalid UTM values. instead — 23 without a letter and zona 23 each redden the Zone box alone, while 99S, shaped like a zone but not one, reddens all three boxes.
One caveat about that box, because it decides whether any of the above applies to you: when Source projection (CRS) is itself a UTM code, the Zone box is not read at all. With SIRGAS 2000 / UTM 23S (EPSG:31983) selected, 22S still gives the 23S answer and 99S gives it with no complaint, while zona 23 shows Invalid UTM values. in red beside a result that is correct. In the converter, set the picker when the picker is on a UTM code, and use the Zone box when the source CRS is a geographic one, as in the cases above.
Which zone is yours
The EPSG cheat sheet answers that under "Picking a UTM zone in Brazil", with a "Zone by zone" list of the codes and a section on the states that span two of them. Then verify rather than trust: gdalsrsinfo -o wkt1 EPSG:31983 prints PROJCS["SIRGAS 2000 / UTM zone 23S" and the neighbouring 31984 prints zone 24S, so one command tells you whether the code in your metadata is the zone you think it is.
The trap: the map still draws it, the export refuses it
If the metres reach you as a Shapefile with no .prj, the shapefile viewer reads them as degrees and says so: the layers row reads 27 polygons · Unknown CRS — assuming WGS 84. It draws the layer anyway, somewhere your states are not, and the picture on screen gives you nothing to argue with — the coordinate system was guessed, and the guess is wrong.
The export is where you get a straight answer. Click Export GeoJSON and no file is written; the viewer stops and says why: Export blocked: this Shapefile has no .prj, so its coordinates were read as degrees and fall outside the valid longitude range. Assign the correct CRS (for example with ogr2ogr -a_srs EPSG:31983) and load the file again. That is the diagnosis and the repair in one message — the missing label is named, and the command that supplies it is the -a_srs of the next section.
It is worth knowing what that file would have contained, because the same numbers still reach you by every other route. Its first pair would have been [-2171693.959168141, -53.911070387188786]: the longitude is your easting, digit for digit, and the latitude is an artefact of the Mercator maths, which pushes the northing through a periodic tan and returns something that looks like a real place. That pair was read in the September 2026 lab behind the missing .prj post, which has the full reproduction, and re-measured for this post at static-page-tools@79fc1f6, identical on the doubles. A longitude of −2,171,693 is a number no longitude can be, and that is precisely the test the refusal runs.
Read the refusal narrowly. It fires when you export, and only when the coordinates leave the ±180° longitude range — which a UTM easting does by four orders of magnitude and a genuine degree coordinate never does, so a .prj-less file whose numbers really are degrees still exports normally. It does not move your point: the layer is still drawn in the wrong place and still flagged as a guess, and the viewer still has no way to know which zone the metres belong to. It tells you the file is unlabelled; it does not label it. Find the zone in the cheat sheet and label it yourself.
Assign or reproject: two verbs
ogr2ogr -a_srs EPSG:31983 fixed.shp in.shp assigns. Before it, ogrinfo -so prints (unknown) under Layer SRS WKT:; after it, PROJCRS["SIRGAS 2000 / UTM zone 23S", with the same Feature Count: 27, the same extent (-2839536.828905, 6233605.421945) - (2201621.719307, 10603897.119783) and the same first vertex -2171693.95916814 8673426.08892961. Nothing moved; the file was labelled.
ogr2ogr -s_srs EPSG:31983 -t_srs EPSG:4326 out.shp in.shp reprojects: the result's extent is (-73.990450, -33.751178) - (-28.847640, 5.271841) and its first vertex -68.792817347 -10.999569268, in Acre. -s_srs is what the missing .prj would have said; -t_srs is where you want to go.
They are not interchangeable, and -a_srs never checks: assign EPSG:4326 to the same UTM file and ogr2ogr exits 0 with no warning, leaving an extent of ±2.8 million "degrees" labelled WGS 84. Get the code right before you write it down.
Test files you can use
IBGE's 2022 mesh of the 27 Brazilian states, 13,717,460 bytes, SHA-256 282ec7f0f0beeeead45e6609f4ffffce161bda04cb8ee0afcad2316d1c841bcb. The download directory carries no licence line of its own, so credit IBGE and check the portal's terms before republishing.
To make the broken variant used above, project it once with ogr2ogr -f "ESRI Shapefile" utm/BR_UF_2022_utm.shp shp/BR_UF_2022.shp -t_srs EPSG:31983, then drop the resulting .shp, .shx and .dbf into the viewer without the .prj.
For teams
A zone number travels in a filename, an email or somebody's memory, and the map that receives the file cannot ask. Geodocs keeps the coordinate system attached to the data on a shared map, so the field team collects and the office reads in one CRS, and the hemisphere letter is never something somebody has to remember to type.