Reproject GeoJSON (4326 ↔ 3857)
Convert coordinates between EPSG:4326 (WGS 84 degrees — what GeoJSON is supposed to hold) and EPSG:3857 (Web Mercator metres — what a lot of GIS exports actually hold). Both directions, with sensible rounding for each.
Reproject GeoJSON (4326 ↔ 3857)
What this tool does
It rewrites every coordinate through the spherical Web Mercator transform, in either direction, leaving geometry structure and properties untouched. Going to 3857, longitude and latitude become metres east and north of the origin at 0°,0°; coming back, those metres become degrees again.
The intent it closes: "these coordinates are in the millions, not in degrees" — or the reverse, when a tool insists on projected input. A GeoJSON file whose coordinates look like [-13627732.06, 4546985.28] is Web Mercator, not WGS 84, and no map library will place it correctly until it is converted.
How this tool works
The spherical Mercator formulas, applied per position.
1. To Web Mercator
X is R · λ and Y is R · ln(tan(π/4 + φ/2)) with R = 6 378 137 m, the WGS 84 semi-major axis — the definition EPSG:3857 uses, treating the ellipsoid as a sphere. Latitudes are clamped just short of ±90° because Y goes to infinity at the poles; the status line reports how many positions were clamped.
2. Back to degrees
The inverse: longitude is x / R in radians, latitude is 2·atan(e^(y/R)) − π/2. The transform is exact in both directions apart from the rounding you choose, so a round trip returns the original coordinates to within that precision.
3. Round appropriately
The defaults differ by direction because the units do: 2 decimals is centimetre resolution in metres, while degrees need 6 or 7 to reach the same. Change the Decimals field after switching direction if you want something other than the default.
Options
Direction
4326 → 3857 when a tool wants projected metres — some tiling utilities, some desktop GIS workflows, or when you want to measure planar distances in metres. 3857 → 4326 to make a projected export usable as real GeoJSON, which is the far more common need.
add legacy crs member
Writes a top-level crs object naming the coordinate system. That member was part of the 2008 GeoJSON specification and was removed in RFC 7946, which fixes the CRS at WGS 84. Some older consumers still read it; strict modern parsers ignore it. Off by default, and worth turning on when handing a 3857 file to something that will otherwise assume degrees.
Example
Input (degrees):
{ "type": "Point", "coordinates": [-122.42, 37.77] }
Output (metres, 2 decimals):
{
"type": "FeatureCollection",
"features": [
{ "type": "Feature", "properties": {},
"geometry": { "type": "Point", "coordinates": [-13627732.06, 4546985.28] } }
]
}
Those two numbers are metres from the origin — about 13,628 km west and 4,547 km north. A quick sanity check: any |X| up to roughly 20,037,508 is a valid Mercator easting, and that number appearing in your data is a reliable sign it is 3857.
Tips & common pitfalls
- RFC 7946 GeoJSON is always 4326. The spec removed the
crsmember and fixed the CRS at WGS 84, which is why a 3857 file breaks every map library until you convert it. - Do not measure in 3857. Mercator distorts area badly away from the equator — Greenland looks continental. Measure with the geodesic area tool instead of projecting first.
- Only these two systems. State plane, UTM, national grids and the rest need a full projection library with datum shifts. This handles the web pair, which is the pair that comes up daily.
- Round-trips are safe. Convert both ways with 7 decimals in degrees and you get your input back — useful to confirm which direction a mystery file needs.
FAQ
How do I tell which projection my file is in?
Look at the numbers. Degrees are within ±180 and ±90; Web Mercator metres run to about ±20 million. Anything with six or more digits before the decimal point is projected.
Is EPSG:3857 spherical or ellipsoidal?
It is defined as spherical Mercator on the WGS 84 ellipsoid's semi-major axis — the pragmatic definition every web map uses, and what is implemented here.
Can it handle UTM or a national grid?
No. Those need datum transformations and zone parameters; use proj4js or a desktop GIS for them.
Will properties change?
No. Only coordinates are transformed; properties, ids and geometry structure are untouched.