Batch Coordinate Converter — WGS84 ↔ UTM

InSAR results arrive in geographic coordinates because satellites orbit a sphere; the CAD drawing, the GIS project and the survey total station live in projected metres because engineers measure in metres. Sooner or later every workflow needs to cross that line, and doing it point-by-point in an online converter is where transcription errors breed. This tool converts entire tables between WGS84 longitude/latitude and UTM coordinates in both directions — with automatic zone detection, CSV and GeoJSON interchange, and the projection mathematics delegated to the widely used proj4js library rather than to hand-typed formulas. The points never leave your browser.

What UTM actually is, in the amount that matters

The Universal Transverse Mercator system divides the world into sixty longitudinal zones, each six degrees wide, and flattens each zone with a transverse Mercator projection tuned to its own central meridian. Coordinates appear as an easting (metres from the zone's false origin — 500,000 m at the central meridian) and a northing (metres from the equator, or from 10,000,000 m false northing in the southern hemisphere). Three practical consequences follow. First, a UTM coordinate is meaningless without its zone: the easting/northing pair repeats across all sixty zones, which is why reverse conversion requires you to state the zone explicitly — the numbers themselves cannot reveal it. Second, near a zone boundary the same physical line can be described in two zones; pick one and stay in it for the whole project, because mixing zones introduces scale differences across the seam. Third, UTM is conformal — shapes are locally preserved and grid north deviates from true north by a small, computable convergence — but distances are not exactly ground distances; high-accuracy engineering work applies the appropriate scale-factor corrections that this tool deliberately does not, because they belong to the survey discipline, not to data preparation.

When you should use this tool

• Feeding InSAR point tables into QGIS, CAD or Google Earth workflows that expect projected metres — or bringing surveyed UTM points back into a geographic-coordinate tool.
• Batch-preparing monitoring point lists: one paste, the whole table, a CSV out with consistent columns instead of sixty trips through a web form.
• Exchanging point sets with GeoJSON-based systems: import a GeoJSON of survey markers, or export your converted results as GeoJSON with the UTM values preserved in the properties.

When NOT to use this tool

• For geodetic survey deliverables. Datum transformations beyond plain WGS84↔UTM (NAD27, regional frames, local mine grids), scale-factor and height-correction reductions, and control-grade requirements all belong in dedicated geodetic software with documented parameters.
• Across hemispheres or zones in one batch. The converter applies one zone per run by design — split the table instead, or the silent mixing will cost an afternoon.
• With coordinates whose provenance you cannot state. No converter fixes data that was collected against an unknown datum; find out what the source actually is first.

Step-by-step usage

1. Choose the direction. Forward (lon/lat → UTM) detects the zone automatically from each point's longitude — the demo button shows this with four points spanning three zones. Reverse (UTM → lon/lat) asks you to state the zone and hemisphere, and the tool holds you to it.
2. Paste the table or import a CSV (forward needs a lon/lat or x/y header; reverse needs easting/northing) or a GeoJSON file for coordinate extraction.
3. Convert, inspect the table, and check the plan-view scatter — a wrongly chosen zone announces itself immediately as points landing thousands of kilometres from their neighbours.
4. Export the results as CSV, or as GeoJSON when the downstream system speaks that dialect.

Common pitfalls & mistakes

• Latitude/longitude order flips. GeoJSON mandates longitude-first; some survey exports are latitude-first. The scatter plot is the fastest way to catch a swap — points appear in the wrong hemisphere or ocean.
• Southern-hemisphere northing panic. South-of-equator northings run from 10,000,000 m downwards. A "negative" northing usually means the hemisphere flag was missing, not that the point is broken.
• The 500,000 illusion. Eastings below 500,000 m are west of the central meridian, not erroneous. Points hugging a zone edge can legitimately sit near 100,000 or 900,000.
• Datum complacency. "UTM" fixes the projection, not the datum. WGS84-based coordinates convert cleanly; legacy NAD27 or local mine-grid values need a real datum transformation first.
• Precision theatre. Six decimal places of longitude are about ten centimetres — quoting more implies equipment that does not exist. Match the printed precision to the survey's reality.

Zone, hemisphere and edge cases at a glance

• Zone arithmetic. Zone = floor((longitude + 180) / 6) + 1. Norway and Svalbard use well-known exemptions in some national workflows; if your project sits there, confirm which convention your downstream systems expect before trusting the automatic assignment.
• High latitudes. UTM distortion grows rapidly poleward of about 80°, where the system was never intended to operate. Polar work switches to UPS or national polar projections.
• GeoJSON axis order. The specification is unambiguous — longitude first, latitude second — yet real files violate it regularly. The import parser treats coordinates as longitude-first and the plan-view scatter will expose violations instantly.
• Northing at the equator. Exactly 10,000,000 m in the southern variant and 0 in the northern; points hovering near the equator need the hemisphere set deliberately, not assumed.
• Batch hygiene. Keep one zone, one hemisphere, one datum per file. The CSV export preserves the zone column so the converted table remains self-describing when it reaches your GIS.

Frequently asked questions

Which datum does the tool assume?

WGS84 throughout, consistent with GNSS and typical InSAR exports. If your source uses a different frame, transform it before conversion — this tool does not hide datum shifts inside the projection.

Why must I enter the zone for reverse conversion?

Because easting/northing pairs repeat in every zone — it is a property of the system, not a limitation of the tool. Guessing would silently place your points in the wrong country.

How accurate is the conversion?

Sub-millimetre at site scales: the proj4js implementation of the standard transverse Mercator series round-trips well below any engineering tolerance. Uncertainty in your input data dwarfs it.

Can it convert my mine's local grid?

Only if the local grid is UTM-compatible. Local engineering grids with custom origins need their own transformation parameters — treat them as a separate datum problem.

Does the scatter map use real basemaps?

No, and that is deliberate: no tile fetches means no data leaves the browser and the tool works offline. The axes are labelled easting/northing or lon/lat for orientation.

Why does my converted table show a zone column for forward conversion?

Because the zone is part of the result: each point's zone is detected from its longitude and written into the output, so a batch that accidentally spans two zones is visible in the CSV instead of being silently merged. If you see two zone values in one run, split the table.

Related tools

The LOS Converter and the Hazard Classifier work in geographic coordinates end to end; this converter is the bridge out to surveying and CAD tooling, and the way surveying data comes back in.