Choosing between EPSG:4326 and EPSG:3857 is one of the most common decisions in geospatial development. Understanding the difference between EPSG 4326 vs 3857 determines how coordinates are stored, how maps render, and whether spatial calculations produce correct results. This guide breaks down both coordinate reference systems, compares their strengths and trade-offs, and explains when to reach for each one.
What Are EPSG Codes?
EPSG codes are numeric identifiers maintained by the EPSG Geodetic Parameter Registry, originally established by the European Petroleum Survey Group. Each code points to a complete definition of a coordinate reference system, including its datum, ellipsoid, projection method, and unit of measure. When two systems exchange geospatial data, the EPSG code tells the receiving side exactly how to interpret the coordinates. For a broader introduction, see our guide on understanding coordinate reference systems in GIS.
EPSG:4326 — WGS 84 Geographic Coordinates
EPSG:4326 refers to the World Geodetic System 1984 (WGS 84) geographic coordinate system. It models the Earth as an ellipsoid and expresses positions as latitude and longitude in decimal degrees. There is no map projection involved — coordinates describe angles from the center of the Earth rather than distances on a flat surface.
WGS 84 is the native CRS of GPS receivers, which is why nearly every location-aware device outputs coordinates in this system. The GeoJSON specification mandates EPSG:4326, and most REST APIs that return geographic data use it as well. When you see a coordinate pair like [-73.9857, 40.7484], that is a longitude/latitude value in EPSG:4326.
- Units: Decimal degrees
- Datum: WGS 84 ellipsoid
- Type: Geographic (unprojected)
- Coordinate order: Longitude, Latitude (in GeoJSON) or Latitude, Longitude (in many other formats)
- Coverage: Worldwide, −90° to 90° latitude
EPSG:3857 — Web Mercator Projection
EPSG:3857 applies a Mercator projection to the WGS 84 ellipsoid, producing coordinates in meters on a flat Cartesian plane. It was popularized by Google Maps in 2005 and is now the standard for slippy tile maps. OpenStreetMap, Mapbox, Bing Maps, and virtually every web mapping library render tiles in this projection. You can view the full parameter definition at epsg.io/3857.
The projection treats the Earth as a perfect sphere rather than an ellipsoid for the forward transformation, which introduces small positional errors of up to 40 km at extreme latitudes. However, this simplification makes tile arithmetic fast and predictable. The projected area extends from roughly −20,037,508 to +20,037,508 meters on both axes, forming a square that can be recursively subdivided into tiles.
- Units: Meters
- Datum: WGS 84 (spherical approximation)
- Type: Projected (Mercator)
- Coordinate range: Approximately ±20,037,508 m on both X and Y
- Latitude limits: ~85.06°N to ~85.06°S (poles are excluded)
EPSG 4326 vs 3857: Side-by-Side Comparison
| Property | EPSG:4326 (WGS 84) | EPSG:3857 (Web Mercator) |
|---|---|---|
| Type | Geographic (unprojected) | Projected (Mercator) |
| Units | Decimal degrees | Meters |
| Datum | WGS 84 ellipsoid | WGS 84 spherical approximation |
| Coverage | Full globe (−90° to 90° latitude) | ~85.06°S to ~85.06°N |
| Area distortion | None (no projection) | Severe at high latitudes |
| Shape preservation | N/A | Conformal (shapes preserved locally) |
| Primary use | Data storage, exchange, GPS | Web map tile rendering |
| Used by | GeoJSON, WFS, GPS devices | Google Maps, OSM, Mapbox |
| Coordinate example | -73.9857, 40.7484 | -8235725, 4975870 |
Coordinate Units: Degrees vs Meters
The most immediate practical difference is the unit of measure. EPSG:4326 coordinates are in degrees, where one degree of latitude is roughly 111 km everywhere, but one degree of longitude shrinks from 111 km at the equator to 0 km at the poles. This variable scale makes naive distance calculations in degrees unreliable without geodesic math.
EPSG:3857 coordinates are in meters measured from the intersection of the equator and the prime meridian. Distances computed from these meter values are only accurate near the equator because the Mercator projection stretches distances progressively toward the poles. For precise distance or area calculations, neither system is ideal — local projected CRS like UTM zones are better suited.
Distortion: How Each System Handles the Globe
Because EPSG:4326 is not projected, it introduces no geometric distortion. The coordinates are raw angular positions on the ellipsoid. However, displaying unprojected coordinates on a rectangular screen still requires a projection at render time, even if it is an implicit equirectangular (Plate Carrée) projection.
EPSG:3857 is a conformal projection, meaning it preserves local angles and shapes. The trade-off is severe area distortion: at 60° latitude, areas appear four times larger than they really are. At 80° latitude, they appear 33 times larger. This is why Greenland looks comparable in size to Africa on Google Maps, even though Africa is roughly 14 times larger in reality. If your application needs accurate area measurements, you must either reproject to an equal-area CRS or use geodesic formulas on EPSG:4326 coordinates.
How Web Mercator Enables Tile-Based Maps
The Mercator projection maps the globe to a square, and that geometric property is the foundation of slippy tile systems. At zoom level 0, the entire world fits in a single 256×256 pixel tile. Each subsequent zoom level divides every tile into four sub-tiles, doubling the resolution. At zoom level 18, the map contains over 68 billion tiles.
This quadtree subdivision works because the Mercator projection produces a perfect square when the latitude is clipped to approximately ±85.06°. Tile coordinates (x, y, z) map directly to pixel ranges in EPSG:3857 meters, making address calculation trivial. Libraries like Leaflet and OpenLayers handle the conversion between EPSG:4326 input and EPSG:3857 tile rendering automatically.
Mercator Projection Math Simplified
The forward Mercator equations convert longitude (λ) and latitude (φ) in radians to projected x and y coordinates in meters:
x = R × λ
y = R × ln(tan(π/4 + φ/2))Here, R is the Earth's radius (6,378,137 m for EPSG:3857). The x-coordinate scales linearly with longitude, while the y-coordinate uses a logarithmic function that stretches spacing between latitude lines as you approach the poles. This stretching is what keeps local shapes intact (conformality) at the expense of accurate area representation.
When to Use EPSG:4326
- Data storage and interchange: Store your canonical geospatial data in EPSG:4326. It is the universal default for GeoJSON, KML, GPX, and most spatial databases.
- GPS and sensor data: Coordinates from GPS receivers, phones, and IoT devices arrive in WGS 84. Converting prematurely adds unnecessary processing and potential precision loss.
- API responses: Most geospatial APIs return coordinates in EPSG:4326. Keeping your pipeline in the same CRS avoids repeated reprojection.
- Geodesic calculations: Libraries like Turf.js and GeographicLib compute geodesic distances and areas on the ellipsoid, requiring EPSG:4326 input.
When to Use EPSG:3857
- Web map rendering: If your application displays an interactive map with raster or vector tiles, the map canvas operates in EPSG:3857.
- Tile overlay alignment: Custom tile layers and WMS services must match the map's native projection to avoid visual misalignment.
- Client-side pixel math: Operations that depend on pixel coordinates — hit testing, buffer rendering, label placement — are simpler in projected meter space.
Practical Tips for Developers
A common pattern in web mapping applications is to store data in EPSG:4326 and display it in EPSG:3857. Mapping libraries handle this reprojection transparently. In Leaflet, for example, you pass GeoJSON in EPSG:4326 and the library projects it to Web Mercator for rendering. You can explore this workflow by loading a file into GeoDataTools.
When performing spatial queries in a database like PostGIS, store geometries in EPSG:4326 using the geography type for accurate geodesic measurements, or in EPSG:3857 using the geometry type for fast planar operations. Index your spatial column with a GiST index regardless of the CRS you choose.
Always validate your data's CRS before combining datasets. Mixing EPSG:4326 and EPSG:3857 without reprojection produces wildly misplaced features — a coordinate like (40.7, -73.9) in degrees would be interpreted as a point less than 100 meters from the origin in EPSG:3857.
FAQ
Can I use EPSG:4326 directly in a web map?
Most web mapping libraries accept EPSG:4326 coordinates as input and internally reproject them to EPSG:3857 for tile-based rendering. You rarely need to convert coordinates manually. However, if you build a custom tile layer, the tile grid itself must be defined in EPSG:3857 to align with standard basemaps.
Why does Web Mercator exclude the poles?
The Mercator projection stretches latitude spacing toward the poles using a logarithmic function that approaches infinity at ±90°. EPSG:3857 clips the map at approximately ±85.06° latitude so the projected area forms a perfect square. This cutoff enables the quadtree tile subdivision that powers every major slippy map provider.
Which EPSG code should I use for accurate area calculations?
Neither EPSG:4326 nor EPSG:3857 is suitable for direct area calculations. Use an equal-area projection like EPSG:6933 (cylindrical equal-area) or the appropriate UTM zone for your region. Alternatively, compute geodesic areas directly on EPSG:4326 coordinates using a library that implements Karney's geodesic algorithm.
Conclusion
The choice between EPSG 4326 vs 3857 comes down to purpose. Use EPSG:4326 for storing, exchanging, and performing geodesic analysis on geospatial data. Use EPSG:3857 for displaying that data on interactive web maps. In most applications, you will work with both — EPSG:4326 as the authoritative data format and EPSG:3857 as the rendering projection. Understanding how these two systems relate ensures your coordinates align, your measurements stay accurate, and your maps display correctly.