Coordinate systems

EPSG:4326 vs EPSG:3857

EPSG:4326 stores positions as latitude and longitude in degrees on the WGS 84 ellipsoid. EPSG:3857 projects those same positions onto a flat square in metres, using spherical maths, so that web map tiles line up. They describe the same points on the ground; they disagree about what a coordinate is. Neither is the right place to measure a distance or an area.

On this page
  1. Side by side
  2. They are not two formats of the same number
  3. Why EPSG:3857 stops at 85.0511 degrees
  4. The sphere-on-ellipsoid shortcut, and what it costs
  5. Why you must not measure in either one
  6. The axis-order trap in EPSG:4326
  7. A rule that works in practice
  8. Try these codes on your own coordinates
  9. Questions people ask

Side by side

 EPSG:4326EPSG:3857
Full nameWGS 84, geographic 2DWGS 84 / Pseudo-Mercator
Coordinate unitsDegrees of latitude and longitudeMetres east and north of the origin
Typical values28.6139, 77.20908594867, 3326595
Coordinate range-90 to 90 lat, -180 to 180 lon±20037508.34 m on both axes
Latitude limitFull globe, poles includedCut off at ±85.0511°, so the map is square
Earth model usedWGS 84 ellipsoidSphere of radius 6378137 m, applied to ellipsoidal latitudes
Shape of the gridNot a grid - degrees are not a constant lengthFlat square grid, which is why tiles work
Distance and areaMeaningless without a geodesic calculationWrong by a factor of 1/cos(latitude), growing toward the poles
Use it forStoring and exchanging positionsDrawing a slippy map
Do not use it forMeasuring in a planar GISMeasuring anything at all

They are not two formats of the same number

A coordinate in EPSG:4326 is an angle. Latitude 28.6139 means 28.6139 degrees north of the equator, measured as an angle from the centre of the WGS 84 ellipsoid. Nothing has been flattened yet, which is why a GPS receiver, a GeoJSON file and a KML placemark all speak it.

A coordinate in EPSG:3857 is a length. The same point in Delhi becomes roughly 8594867 east, 3326595 north - metres from the intersection of the equator and the prime meridian, after the globe has been unrolled onto a square. That unrolling is a choice, and every choice of projection trades away something.

So converting between them is not a formatting change like decimal degrees to degrees-minutes-seconds. It is a projection, and it is lossy in the sense that the distortions it introduces are baked into the numbers you end up with.

Why EPSG:3857 stops at 85.0511 degrees

Mercator sends the poles to infinity: as latitude approaches 90 degrees the northing grows without bound. A tiled web map needs a finite, square world so that zoom level 0 is one tile, zoom 1 is four, and so on.

Cutting the map at latitude 85.0511287798066 degrees makes the northing extent exactly equal to the easting extent - 20037508.34 metres each way, which is half the circumference of a sphere of radius 6378137 m. The world becomes a square, the tile pyramid works, and Antarctica and the high Arctic are simply not on the map.

This is why a dataset covering Svalbard or an Antarctic survey cannot be displayed in Web Mercator without clipping, and why polar work uses something like EPSG:3413 or EPSG:3031 instead.

The sphere-on-ellipsoid shortcut, and what it costs

EPSG:3857 does something a cartographer would normally call an error: it takes latitudes defined on the WGS 84 ellipsoid and pushes them through spherical Mercator formulas, as if the earth were a ball of radius 6378137 m. A true ellipsoidal Mercator of WGS 84 exists and is EPSG:3395.

The two disagree. The northing from Pseudo-Mercator departs from true ellipsoidal Mercator by about 21 km at 30 degrees, 30 km at 45 and 37 km at 60 - the gap widens with latitude rather than peaking in the middle - and the scale differs by a few tenths of a percent. On a screen at zoom 12 you will never see it. In a survey deliverable it is a disqualifying error.

That shortcut is also why the authority spent years refusing to issue a code for it. The projection circulated as the unofficial EPSG:900913 - a numeric pun on 'google' - then as the deprecated EPSG:3785, before being blessed as EPSG:3857. If you meet 900913 in an old configuration file, it is the same projection.

Why you must not measure in either one

In EPSG:4326 the units are degrees, and a degree is not a fixed length. One degree of latitude is about 111.32 km everywhere. One degree of longitude is about 111.32 km at the equator, about 78.7 km at 45 degrees, and zero at the pole, because it shrinks with the cosine of the latitude. Software that computes a planar area from degree coordinates and reports 'square degrees', or silently labels it square metres, is producing a number with no physical meaning.

EPSG:3857 is worse, because its answer looks plausible. Web Mercator inflates by 1/cos(latitude) in each direction, so the area error is 1/cos²(latitude). At the equator the scale is true. At 45 degrees lengths are inflated about 1.41 times and areas about 2 times. At 60 degrees - Oslo, Helsinki, Anchorage - lengths are doubled and areas are four times too large. A parcel measured in Web Mercator near 60 degrees north reads four times its real size, with no warning.

The correct move is to measure in a projection designed for the place: a UTM zone, a State Plane zone, or a national grid. Or measure geodesically on the ellipsoid, which is what this site's area calculator does, so the answer does not depend on a projection at all.

The axis-order trap in EPSG:4326

The EPSG registry defines EPSG:4326 with latitude first, then longitude. Most of the web does the opposite. GeoJSON mandates longitude first in RFC 7946. KML writes longitude first. PostGIS, Leaflet, OpenLayers and proj4 all have their own conventions, and some of them differ between versions and between the WMS 1.1.1 and WMS 1.3.0 specifications.

The practical symptom is unmistakable: your data lands in the Gulf of Guinea, or in the sea off Somalia, or latitude and longitude are plainly swapped. If a point near Delhi shows up near 77 degrees north, 28 degrees east, you have an axis-order problem and not a datum problem.

The fix is to decide the order at the boundary of your system and state it explicitly, rather than trusting that EPSG:4326 means one thing everywhere. CRS84 exists precisely to name the longitude-first interpretation.

A rule that works in practice

Store and exchange in EPSG:4326. It is unambiguous about the datum, every tool reads it, and it does not bake a projection into your archive.

Display in EPSG:3857 if you are drawing a slippy map, because that is what the tiles are in and fighting it costs more than it saves.

Measure in a local projected CRS, chosen for the area you are working in, or measure geodesically. Never in 4326, never in 3857.

If a deliverable has to be in one system end to end, pick the local projected one and convert for display, not the other way round.

Try these codes on your own coordinates

Each one opens the converter with that system already selected. Nothing is uploaded; the projection runs in your browser.

Questions people ask

Is EPSG:4326 the same as WGS 84?

Almost, and the difference matters in careful work. WGS 84 is a datum - a definition of where the earth's centre and axes are, and the ellipsoid used. EPSG:4326 is a coordinate reference system that uses that datum and expresses positions as latitude and longitude in degrees. EPSG:3857 also uses the WGS 84 datum, so 'WGS 84' alone does not tell anyone which of the two you mean.

Can I just convert EPSG:3857 to EPSG:4326 to fix my measurements?

Converting back gives you the correct positions, but it does not give you a system you can measure in - degrees still are not a length. If your areas or distances were computed in Web Mercator they are wrong and must be recomputed, either in a local projected CRS such as a UTM zone, or geodesically on the ellipsoid.

What is EPSG:900913?

The unofficial code the spherical Web Mercator projection circulated under before it was standardised, named as a numeric pun on 'google'. EPSG:3785 was an early official attempt and is deprecated. EPSG:3857 is the current code. All three refer to the same projection, so a legacy file declaring 900913 can be read as 3857.

Why does my Web Mercator area come out too big?

Because Web Mercator inflates scale by 1/cos(latitude), so areas are inflated by 1/cos²(latitude). At 45 degrees that is roughly double; at 60 degrees roughly four times. The effect is zero at the equator, which is why the bug often survives testing on data near it.

Which EPSG code should I use for drone mapping?

Capture and store in EPSG:4326, because that is what the GPS in the aircraft produces. Process and measure in the UTM zone covering the site, or in the national grid your client reports in. Use EPSG:3857 only if you are serving tiles.

Need the zone for a specific place? The UTM zone finder gives the zone, EPSG code and MGRS grid square from a map click.