Question one: storing, drawing, or measuring?
These three jobs want different things, and no single CRS does all of them well. Trying to force one is the root of most of the trouble.
Storing and exchanging: use a geographic CRS, almost always EPSG:4326. It does not bake a projection into your archive, every tool reads it, and it is what GNSS hardware produces. Store in it even if you never display it.
Drawing a web map: use EPSG:3857. The tiles are in it. Fighting that costs more than it saves, and the distortion does not matter when the job is to put a dot in roughly the right place on a screen.
Measuring a distance, an area or a volume: use a projected CRS chosen for the place, or compute geodesically on the ellipsoid. Never measure in degrees, and never measure in Web Mercator, which inflates area by 1/cos²(latitude) - roughly double at 45 degrees and roughly four times at 60.
Question two: where is the work?
If the site is in the United States and there is any survey control involved, use the State Plane zone for that area, on NAD83. State Plane zones are small and tuned, holding distortion to around one part in ten thousand, and almost all US agency and cadastral data is already in them. The EPSG code depends on the state, the zone and the units.
If the country has a national grid and the deliverable is local, use it. The British National Grid is EPSG:27700, Lambert-93 for France is EPSG:2154, the Dutch RD New is EPSG:28992, New Zealand Transverse Mercator is EPSG:2193, and Switzerland's LV95 is EPSG:2056. These exist because someone already solved the distortion problem for that country.
Otherwise use the UTM zone covering the site. UTM divides the world into 6-degree strips, each with its own transverse Mercator projection, scale factor 0.9996 on the central meridian. That shrinks distances by one part in 2500 on the central meridian itself, or 40 cm per kilometre; scale climbs back through unity toward the edge of the strip, reaching about one part in 1000 near the equator, so the worst case in a zone depends on where in it you are. That is fine for mapping and usually fine for drone work.
The UTM codes follow a pattern worth memorising: EPSG:326xx for zone xx north and EPSG:327xx for zone xx south, on WGS 84. Delhi sits in zone 43 north, so EPSG:32643. If you do not know the zone, the zone finder will tell you from a click on the map or from coordinates.
Question three: what tolerance?
Metres. Anything consistent will do. Store in EPSG:4326, draw in EPSG:3857, and stop worrying.
Decimetres. Use the right projected CRS for the area and get the datum right. A proj4-based transformation is adequate here, which means browser tools are adequate.
Centimetres. Now the datum realisation and the epoch matter, grid-based datum transformations matter, and the vertical datum matters at least as much as the horizontal one. This is the point where browser-side conversion stops being enough and you need NGS tooling, a full GIS with grid files installed, or your survey software.
A useful sanity check: if your stated tolerance is tighter than the error introduced by your datum assumptions, the tolerance is fiction. An RTK drone survey sold on 2 cm accuracy, delivered in the wrong datum, is a 1-2 metre product with a 2 cm label.
When the site straddles two UTM zones
Corridor projects - roads, pipelines, transmission lines, rivers - routinely cross a zone boundary, and a 6-degree strip is only about 670 km wide at the equator and much narrower further north.
There are three honest ways out - extend one zone past its edge and document it, split the deliverable at the boundary, or move to a grid built to span the area - and the UTM zone by city guide works through the trade-offs and carries the distance to the boundary for the places people ask about.
What you must not do is silently mix zones inside one dataset. Easting values restart at each zone, so two points in different zones can share coordinates while being hundreds of kilometres apart, and nothing in the file will warn you.
The unit traps that actually cost money
The US survey foot and the international foot are not the same. One international foot is exactly 0.3048 m. One US survey foot is 1200/3937 m, about 0.30480061 m. The ratio differs by two parts per million, which sounds harmless until you remember that the error scales with the coordinate, and State Plane eastings run to millions of feet. On a real California easting that is about 4 m on the ground. The State Plane guide works the arithmetic and gives the codes.
This is why EPSG distinguishes them: look for 'ftUS' versus 'ft' in the CRS name, and treat a file that just says 'feet' as under-specified. The National Geodetic Survey formally deprecated the US survey foot at the end of 2022, so new work should use the international foot or metres - but decades of existing data are in survey feet and will be for a long time.
The second trap is the vertical. Horizontal and vertical datums are independent, and heights are where the large silent errors live. An ellipsoidal height from GNSS is not an orthometric height above mean sea level, and the two can differ by tens of metres. A drone that reports 120 m altitude is usually reporting something different from what a surveyor means by 120 m.
A short decision table
Storing drone imagery or GNSS output, anywhere: EPSG:4326.
Serving a slippy map: EPSG:3857.
Measuring area or distance, no survey control, anywhere: the UTM zone for the site, or a geodesic calculation.
US project with survey control: the State Plane zone on NAD83, in the units the client reports in, stated explicitly.
Project in a country with a national grid: that grid.
Polar work: EPSG:3413 for the Arctic or EPSG:3031 for Antarctica, because Web Mercator does not reach past 85 degrees.
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
What is the difference between a geographic and a projected coordinate system?
A geographic CRS gives positions as angles - latitude and longitude on an ellipsoid - so it has no distortion but also no usable units of length. A projected CRS flattens the ellipsoid onto a plane and gives metres or feet, which you can measure in, at the cost of distortion that grows with distance from the projection's design area.
Is UTM or State Plane more accurate?
State Plane, within the United States. Its zones are smaller and tuned per state, holding distortion to roughly one part in ten thousand against the one part in 1000 a UTM zone can reach near its edge. UTM's advantage is that it covers the whole world with one consistent scheme, which matters when you work in several countries.
How do I find the UTM zone for my site?
Zone number is floor((longitude + 180) / 6) + 1, and the hemisphere decides whether the EPSG code starts 326 for north or 327 for south. The zone finder does it from a map click, typed coordinates or your current location, and gives the EPSG code and MGRS grid zone with it.
Can I use EPSG:4326 to calculate an area?
Not in a planar GIS, because degrees are not a fixed length - a degree of longitude shrinks from about 111 km at the equator to nothing at the pole. Either project to a suitable CRS first or compute the area geodesically on the ellipsoid, which is what this site's area calculator does so the answer does not depend on a projection.
What EPSG code should I use for drone mapping?
Capture and store in EPSG:4326 because that is what the aircraft produces. Process and measure in the UTM zone covering the site, or in the national or State Plane grid your client reports in. Use EPSG:3857 only if you are publishing tiles. Decide the output CRS before the flight, not after.