Coordinate converter: WGS 84, UTM, Web Mercator and Gauss-Kruger

Coordinate converter

Source system

Target system

Convert a list of points and download the file

Paste a list, one point per line: “name;first coordinate;second coordinate”, or just the two coordinates. Semicolon, tab and comma all work as separators, and degrees may be decimal or degrees-minutes-seconds. The systems and the axis order come from the fields above. A single point is a list too. Everything is computed in your browser — the list is not uploaded anywhere.

GeoJSON is written in WGS 84 only: the specification knows no other system, and metres inside it are read silently and wrongly by every GIS. DXF is the opposite — a projected system only, because its drawing unit is a metre and degrees make no sense in it. CSV is always available.

The datum shift between Pulkovo 1942 (SK-42) and WGS 84 uses a seven-parameter Helmert transformation (towgs84), accurate to some 1–3 metres. Precise surveying needs the official NTv2 grid shifts, and those are not applied in a browser; for reference and design work this is enough. For Russian MSK zones the source of the projection parameters, the date we read them and how trustworthy that source is are printed next to the result.

What this is

Type a pair of coordinates, pick the source and the target system, and read the result immediately. The converter is a page, not a queue: there is no upload step and no waiting.

Everything is computed on your device by the open proj4 library. The coordinates you type never reach our server, and neither does a list you paste or a file you drop into the batch field — which is what makes the tool usable for data you are not allowed to send anywhere.

Three families of systems are supported: geographic WGS 84 (EPSG:4326) in decimal degrees or degrees-minutes-seconds, projected UTM and Web Mercator, and the six-degree Gauss-Kruger zones on Pulkovo 1942. Anything else is covered by the custom proj4 mode.

Working with Russian data? The Russian-language page of this tool covers MSK zones in detail, and the blog explains how UTM and MSK zones relate.

How to convert coordinates in three steps

  1. Pick the two systems. Choose what your numbers are in and what you want them in: WGS 84, a UTM zone, Web Mercator, a Gauss-Kruger zone, or «custom proj4 string» for a system that is not in the list.
  2. Check the axis order. Set the axis switch on each side: surveying order (X = northing, Y = easting) or GIS order (lon/lat, E/N). This single switch removes the most common reason for a result that looks plausible and lands in the wrong place.
  3. Convert, then export. Read the converted pair with explicit labels for north and east, copy it, or paste a whole list into the batch field and download the result as CSV, GeoJSON or DXF.

What the converter does

The tool transforms a pair of coordinates between geographic and projected systems. Geographic input is WGS 84 / EPSG:4326, typed either as decimal degrees (55.7558) or as degrees-minutes-seconds (55 45 20.9, 55°45'20.9", N 55°45'20.9"); the geographic result is printed in both forms.

On the projected side there are all 60 UTM zones in both hemispheres, Web Mercator (EPSG:3857) — the system of web map tiles, not a system for measuring distances — and the six-degree Gauss-Kruger zones on the Krassowsky ellipsoid in Pulkovo 1942. The datum shift between Pulkovo 1942 and WGS 84 uses a seven-parameter Helmert transformation, which is accurate to roughly one to three metres.

A system that is not in the list is not a dead end: pick «custom proj4 string» and paste the definition of your CRS. Whatever proj4 understands, the page understands too, because the page is proj4 — the same library that runs inside most desktop GIS.

Pick the right UTM zone, not just the right numbers

A UTM zone is six degrees wide, and the neighbouring zone returns a perfectly believable answer for a point that actually sits hundreds of kilometres away. That is why a wrong zone costs days: the numbers have the right shape, so the error is looked for everywhere except in the choice of zone.

When the source system is geographic, the longitude of the point is known, so the converter checks the zone for you: if the point does not fall inside the zone you picked, it says so and names the zone that fits. Between two projected systems that check is impossible — nobody knows where the point is until it has been converted, which is precisely the moment when the mistake is already made.

Axis order: northing/easting against lon/lat

The most frequent mistake in coordinate conversion is not the projection at all — it is the order of the two numbers. Surveying practice writes X for northing and Y for easting; geographic notation says latitude first, longitude second; and most GIS software works in lon/lat or E/N, easting first. All three are right, and all three disagree.

Each side of the converter therefore carries an explicit axis switch, and both the input fields and the result are labelled with what is north and what is east. If your outline comes out mirrored, rotated or shifted into the sea, this switch is almost always the reason — not the numbers.

Batch conversion and file export

Converting points one by one is an evening's work once there are thirty of them, so the page has a batch field: paste a list — one point per line, «name;first;second» or just the two coordinates — or pick a .csv or .txt file, and take the result as a file. Separators may be a semicolon, a tab or a comma, degrees may be decimal or degrees-minutes-seconds, and a point name is kept if your list has one.

Export formats are CSV, GeoJSON and DXF — but not every format into every system, and that limit is deliberate. GeoJSON exists in WGS 84 only by specification: writing metres into it produces a file that every GIS reads silently and wrongly. DXF is the opposite — a projected target only, because the drawing unit of a DXF is a metre and degrees are meaningless in it. CSV is always available and carries a line about where the numbers came from, because the file will travel by mail without the page.

Lines that could not be parsed are not dropped in silence: the converter names them by line number and says what is wrong with each one. The list itself stays in the browser — parsing, conversion and file building all happen on your device.

Common EPSG codes

EPSG codes are the short way to say which system a file is in, and four of them cover most of the everyday work. The table below is the quick reference; the article on EPSG codes linked at the bottom of the page explains where the registry comes from and how to read a code you have never seen.

EPSGSystemWhat it is
EPSG:4326WGS 84Latitude and longitude in degrees. What GPS returns and what GeoJSON is written in.
EPSG:3857WGS 84 / Pseudo-MercatorWeb Mercator, the system of web map tiles. Metres, but not for measuring: the scale factor grows with latitude.
EPSG:32601-32660WGS 84 / UTM zones 1N-60NNorthern hemisphere. The last two digits are the zone number: EPSG:32637 is UTM zone 37N.
EPSG:32701-32760WGS 84 / UTM zones 1S-60SSouthern hemisphere, same zone numbering, a false northing of 10 000 000 m.
EPSG:4284Pulkovo 1942The geographic system behind SK-42 and its Gauss-Kruger zones, on the Krassowsky ellipsoid.

Russian coordinate systems (SK-42, Gauss-Kruger, MSK)

The converter computes Russian systems as well: the Gauss-Kruger zones of Pulkovo 1942 (SK-42) are in the list, and the local MSK systems of Russian regions are available with their projection parameters and a note on where those parameters were taken from. What we do not have are the official transition keys to the state coordinate system: in Russia they are issued by the Federal Spatial Data Fund under a contract. For cadastral and surveying work this conversion is therefore not valid — it is for orientation, for a design underlay and for checking where a point will land. The Russian-language page of this tool goes into the detail, and the blog explains how UTM and MSK zones relate to each other.

Nothing leaves your browser

There is no hidden round trip. The projection maths, the parsing of your list and the building of the CSV, GeoJSON or DXF file all run in the page; the only request the tool ever makes is for the parameters of a Russian MSK zone, and that request carries the number of the region and nothing else.

Practically, that means you can convert coordinates from a client's survey, an internal database or an NDA-covered project without those coordinates becoming someone else's log entry.

Questions and answers

What is EPSG:4326?

EPSG:4326 is WGS 84 in geographic coordinates: latitude and longitude in degrees on the WGS 84 ellipsoid. It is what a GPS receiver reports and the only system a GeoJSON file may be written in. It is not a projection, so it has no metres and no scale — for measuring, convert to UTM first.

What UTM zone am I in?

The zone number follows from longitude: zone = floor((longitude + 180) / 6) + 1, with the hemisphere deciding N or S. You do not have to count, though — convert from WGS 84 and the page checks the zone for you, naming the right one if the point falls outside the zone you chose.

What is the difference between EPSG:4326 and EPSG:3857?

They hold the same positions on the same datum, but 4326 states them as degrees and 3857 projects them into metres for web map tiles. Web Mercator distorts distance and area badly away from the equator, so it is fine for drawing a map and wrong for measuring one.

Why does my GeoJSON look wrong in another program?

Almost always because it holds projected metres rather than degrees, or because latitude and longitude are swapped. The GeoJSON specification allows WGS 84 only, so the converter refuses to export metres into it; and the axis switch fixes the swapped pair.

Can I convert a list of points?

Yes. Paste the list into the batch field — one point per line, with or without a name — or pick a .csv or .txt file, and download the result as CSV, GeoJSON or DXF. Lines that cannot be parsed are reported by line number instead of being dropped.

Do you store my coordinates?

No. The conversion runs entirely in your browser through the open proj4 library; what you type is never sent anywhere. The only request the tool makes is for the parameters of a Russian MSK zone, and it carries the region number alone.

How accurate is the shift between Pulkovo 1942 and WGS 84?

A seven-parameter Helmert transformation gives roughly one to three metres across Russia — enough for reference, for a design underlay and for checking where a point lands. Precise geodesy uses the official NTv2 grid shifts, which cannot be applied in a browser.

Can I use a coordinate system that is not in the list?

Yes: choose «custom proj4 string» and paste the definition of your CRS. The page runs proj4, so anything proj4 understands — national grids, local systems, a datum with its own towgs84 parameters — converts here as well.