Map Coordinate Converter
Convert a single point between common geographic and projected coordinate systems: WGS84 (GPS, international), GCJ-02 (Amap, Tencent, Google China), BD-09 (Baidu lng/lat), BD-09MC (Baidu Mercator), CGCS2000 (China geodetic datum), Web Mercator (Google, OSM, Mapbox tiles), plus EPSG presets for Europe, North America, the UK, Japan, Australia, and France. Custom EPSG codes are fetched on demand from epsg.io and added to the result list. Every conversion runs locally in the browser; your coordinates never leave the device.
- Covers the four China systems in one panel: WGS84 ↔ GCJ-02 ↔ BD-09 ↔ BD-09MC, so map-source offsets stop biting you
- Global-friendly: WGS84, Web Mercator, CGCS2000, ETRS89, NAD83, OSGB36, JGD2011, GDA2020, Lambert-93 built in
- Type any EPSG code; the tool pulls the proj4 definition from epsg.io and covers thousands of regional grids
- One input expands into every target CRS at once — no source ↔ target toggling
- GCJ-02 / BD-09 results are flagged as approximate so they are not mistaken for meter-grade GPS
GPS, Google Maps (outside China), OSM, and most non-Chinese APIs use WGS84.
Lng/lat typically uses 6–8 places, projected meters 2–4. Auto picks a sensible default per CRS type.
Fetches the proj4 definition from epsg.io — covers thousands of regional grids.
- Longitude
- 116.397428
- Latitude
- 39.90923
- X
- 12,957,302.4146
- Y
- 4,852,760.5844
- Longitude
- 116.40367163
- Latitude
- 39.91063351
- Longitude
- 116.4100441
- Latitude
- 39.91697286
- X
- 12,958,847.8339
- Y
- 4,826,208.9639
- Longitude
- 116.397428
- Latitude
- 39.90923
- Longitude
- 116.397428
- Latitude
- 39.90923
- Longitude
- 116.397428
- Latitude
- 39.90923
- X
- 5,630,579.5125
- Y
- 7,767,574.6702
- Longitude
- 116.397428
- Latitude
- 39.90923
- Longitude
- 116.397428
- Latitude
- 39.90923
- X
- 7,427,213.3545
- Y
- 11,743,911.4685
Overview
Converting the same geographic point between coordinate systems comes up constantly in mapping work, location-API alignment, cross-dataset cleanup, and cross-region collaboration. This tool puts China-specific encrypted offsets and global EPSG projections in one panel so you stop jumping between calculators.
- 01
All four China systems in one panel
WGS84, GCJ-02, BD-09, BD-09MC converted side by side. Device GPS gives WGS84; Amap, Tencent, and Google China use GCJ-02; Baidu uses BD-09; tile math wants BD-09MC. Copy-ready output for every map SDK.
- 02
Global systems + thousands of EPSG codes
WGS84, Web Mercator, CGCS2000 built in, plus presets for Europe (ETRS89), North America (NAD83), the UK (OSGB36), Japan (JGD2011), Australia (GDA2020), and France (Lambert-93). The custom EPSG input pulls definitions from epsg.io for everything else.
- 03
One input, every target at once
No need to pre-select a target. Enter a single point and every built-in CRS produces its equivalent immediately — copy the row you need.
- 04
Encrypted offsets are flagged
GCJ-02 and BD-09 are non-linear offsets applied by the China survey bureau. Their rows carry an "≈" badge so they are not mistaken for meter-grade GPS in surveying or autonomous-driving contexts.
- 05
Web Mercator for tile math
Google Maps, OSM, Mapbox, and Leaflet tiles use EPSG:3857 (Web Mercator) in meters. Converting lng/lat to X/Y lets you compute TMS/XYZ tile indices, render heatmaps, or stack raster layers.
- 06
Local processing — coordinates never upload
Offsets and proj4 transforms run inside the browser. Only the "custom EPSG" path makes a network request, and only to fetch the proj4 definition — your coordinate values are never sent.
How to use
End-to-end inside one panel: pick the source CRS, type the coordinate, scan the conversions, copy what you need.
- 01
Pick the source CRS that matches the input data — device GPS → WGS84, Amap/Tencent export → GCJ-02, Baidu export → BD-09.
- 02
Geographic CRS: choose the input order — longitude first (ISO) or latitude first (Google Maps style). Projected CRS take X and Y directly.
- 03
Type the two values. Decimals, negatives, and scientific notation (e.g. 1.5e7) are accepted.
- 04
On the right, every target CRS expands automatically; the source row is highlighted and offset rows carry "≈".
- 05
Adjust decimal places, then click Copy on the row you need and paste it into code, a ticket, or a map SDK call.
- 06
For other regional grids, type the EPSG code in the Custom EPSG field (e.g. 32650 for UTM 50N); the tool fetches the definition from epsg.io and adds it to the list.
Details
One panel for China systems, global projections, regional national grids, and any EPSG code, with clear accuracy notes.
- China: WGS84, GCJ-02, BD-09, BD-09MC, CGCS2000 all built in
- Global: WGS84 (EPSG:4326) and Web Mercator (EPSG:3857)
- Regional presets: ETRS89, NAD83, OSGB36 (British National Grid), JGD2011, GDA2020, Lambert-93
- Custom EPSG: type a code and the proj4 definition is fetched from epsg.io
- Encrypted offsets: GCJ-02 / BD-09 use the gcoord algorithm, matching Amap and Baidu SDK output
- Projected math: proj4js under the hood, aligned with QGIS, ArcGIS, and PostGIS to meter precision
- One input expands into every target CRS — no source / target toggling
- Encrypted-offset rows carry "≈" so they are not used as meter-grade GPS
- Geographic CRS support two input orders: longitude first or latitude first
- Projected CRS take X / Y directly, in meters
- Decimal places: auto / 4 / 6 / 8 / 10, with a sensible auto default per CRS type
- Live range validation: ±180 longitude, ±90 latitude, ±85 for BD-09 / GCJ-02
- Sample coordinates per source CRS for quick sanity-checks
- All parsing, offsets, and projection math run locally — coordinates never upload
- Only the custom EPSG path makes a network request, and only to fetch a proj4 definition
Use cases
Coordinate conversion exists so data lines up across map sources and standards. The most common situations follow.
-
Device GPS onto a mainland-China map
Car-machines, phones, and IoT devices output WGS84. Plotting WGS84 directly on Amap, Tencent, or Baidu produces tens to hundreds of meters of offset. Convert to GCJ-02 (Amap/Tencent) or BD-09 (Baidu) before display.
-
Aligning mixed-source data
An order has a shipping address from Amap (GCJ-02), a delivery address from Baidu (BD-09), and a warehouse from internal GIS (WGS84). Normalize everything to WGS84 before distance, geofence, or clustering math.
-
Publishing to international maps (OSM / Google / Mapbox)
OpenStreetMap, Google Maps, and Mapbox all use WGS84 + Web Mercator. Convert GCJ-02 / BD-09 from Chinese map data back to WGS84 so locations render correctly on international maps.
-
Tile maps and raster overlays
Leaflet, Mapbox GL, and OpenLayers tiles use EPSG:3857 (Web Mercator) in meters. Lng/lat → X/Y feeds tile-index math, heatmap rendering, and raster overlays.
-
Statutory survey work
Chinese government mapping, planning, and procurement projects require CGCS2000. It agrees with WGS84 to within meters, but submissions must be labeled CGCS2000 for compliance.
-
Europe, North America, Japan, Australia projects
Europe uses ETRS89, North America uses NAD83, the UK uses OSGB36, Japan uses JGD2011, France uses Lambert-93. When delivering data into a region, submit in that region's statutory datum.
-
GIS dataset migration and cleanup
Shapefiles, GeoJSON, and CSV files often lack CRS metadata. Drop a known landmark (e.g. Tiananmen, Sydney Opera House, Eiffel Tower) into the tool and compare against canonical coordinates to identify the source system.
-
API field and docs alignment
Amap, Baidu, and Tencent docs specify the expected CRS; OSM and Mapbox default to WGS84. Confirming the CRS before integration removes a class of "location drift" tickets.
See also
Need to convert distance, area, or altitude between physical units? Use Unit Converter . Need to switch encoded values (such as tile Z/X/Y) between bases? Use Number Base Converter .
Best practices
Conversion is deterministic, but how you label the source CRS, store the values, and align precision is what decides whether downstream code breaks.
- Store WGS84 lng/lat in databases and logs (or geometry columns with explicit SRID); convert at the presentation layer for the target map SDK. Do not mix GCJ-02 and WGS84 in the same column.
- Encode the CRS in field names: lngWgs84, latGcj02, xMercator, yMercator. A naked "longitude" field is a future bug.
- PostGIS / MySQL geometry columns must specify SRID (4326 WGS84, 3857 Web Mercator, 4490 CGCS2000). SRID 0 is a foot-gun.
- When integrating mainland-China map SDKs: Amap and Tencent want GCJ-02, Baidu wants BD-09. When integrating Google Maps (outside mainland China), Mapbox, OSM, or Leaflet, use WGS84 + Web Mercator.
- For high-volume work prefer server-side proj4 / PostGIS / GeoPandas. This tool is best for ad-hoc verification, debugging, and single-point conversions.
- Record the conversion path and algorithm version when storing converted coordinates — GCJ-02 / BD-09 formulas are maintained by the survey bureau and library implementations can drift by sub-meter.
- Do not treat GCJ-02 as "WGS84 with a constant offset." The offset is non-linear and the inverse is numerical, so meter-level uncertainty is unavoidable.
- When delivering to projects that use a regional datum (NAD83, ETRS89, JGD2011, OSGB36 …), confirm the EPSG code on epsg.io. Do not substitute WGS84 for regional datums.
Limitations
The tool focuses on 2D horizontal coordinate conversion. Heights, large datasets, and exact inverses of encrypted offsets are out of scope.
- No elevation conversion. WGS84 ellipsoid height and orthometric height (e.g. EGM96 / EGM2008 geoid) differ by tens of meters and need a dedicated geoid model.
- No bulk dataset conversion. The tool handles one point at a time; for thousands of rows use PostGIS, GeoPandas, ogr2ogr, or the proj CLI.
- GCJ-02 / BD-09 inverse transforms are numerical approximations, not closed-form solutions. Residuals are typically sub-meter; for surveying or planning, use official algorithms.
- CGCS2000 ≈ WGS84 numerically (within meters) but the semantics differ. Statutory submissions must be labeled CGCS2000 rather than silently substituted.
- Custom EPSG loading depends on epsg.io being reachable. The tool reports a load failure on network errors.
- No automatic CRS detection — given an unknown coordinate, this tool cannot reverse-engineer its system. Use a known landmark to triangulate instead.
- Legacy datums (Beijing 1954, Xi'an 1980) are not preset. Load them via custom EPSG (e.g. EPSG:2436 for Beijing 1954 Gauss-Krüger zone 13).
- Not a replacement for full GIS software (raster reprojection, vector clipping, CRS database management).
FAQ
The most-searched questions when integrating maps, aligning location APIs, working across regions, or doing survey work.
What is the difference between GCJ-02, BD-09 and WGS84?
WGS84 is the GPS, internationally standard lng/lat. GCJ-02 ("Mars coordinates") is a non-linear encrypted offset of WGS84 applied by the China survey bureau, active only inside mainland China; used by Amap, Tencent, and Google China. BD-09 is Baidu's additional offset on top of GCJ-02, used only by Baidu Maps.
Why does my GPS coordinate appear offset by ~50 m on a China map?
Device GPS outputs WGS84. The major China maps (Amap, Tencent, Baidu) use GCJ-02 or BD-09. Plotting WGS84 directly produces 50–500 m of systematic offset, often into the wrong lane or adjacent block. Convert to GCJ-02 or BD-09 first.
What CRS do Amap, Tencent, and Google China use?
All three use GCJ-02. So coordinates passed between them need no conversion; only when crossing to Baidu (BD-09) or to OSM / Google Maps outside mainland China (WGS84) is conversion required.
What CRS does the Baidu Maps API use?
The Baidu Maps JS API uses BD-09 for lng/lat and BD-09MC (Baidu Mercator, meters) for tile space. Other sources must be converted to BD-09 first, or routed through BMap.Convertor on Baidu's servers.
Are CGCS2000 and WGS84 the same?
No. CGCS2000 is China's statutory geodetic datum; WGS84 is the international GPS reference. They use different ellipsoids (GRS80 vs WGS84) and agree numerically to within meters in mainland China, but cannot be substituted in official submissions.
What is the relationship between Web Mercator (EPSG:3857) and lng/lat?
Web Mercator is WGS84 lng/lat projected onto a plane via a normal-aspect conformal cylindrical projection, in meters. Google Maps, OSM, Mapbox, and Leaflet tiles use it. Converting lng/lat to X/Y enables tile-index math, heatmap rendering, and distance estimation (mind area distortion at high latitudes).
How should I store Chinese coordinates in PostGIS?
Store WGS84 (SRID 4326) by default. If you need the China statutory datum, use CGCS2000 (SRID 4490). Do not store raw GCJ-02 / BD-09 — they are not standard SRIDs and ST_Distance, ST_Within and friends will return wrong results. Convert at the presentation layer.
How do I look up a specific EPSG definition?
Enter the code at epsg.io to see WKT and proj4. The Custom EPSG field in this tool fetches the proj4 string and adds the CRS to the result list — works for UTM zones (32601–32660 / 32701–32760), national grids, Lambert / Albers, and more.
Is the GCJ-02 → WGS84 inverse accurate?
Only approximately. GCJ-02 is non-linear and has no closed-form inverse; libraries iterate numerically with sub-meter residuals. For surveying or HD-map work, use official algorithms or a commercial SDK rather than an open-source approximation.
Do I need to convert GPS coordinates outside China?
The GCJ-02 offset is active only inside mainland China. Hong Kong, Macau, Taiwan, and any location abroad have identical WGS84 and GCJ-02 values — international maps can consume them directly. When calling a China map SDK, however, you still pass the field the SDK expects.
How do I use the British National Grid (OSGB36)?
OSGB36 is a transverse Mercator projection (EPSG:27700) in meters, designed so locations encode as 6-digit easting/northing pairs. UK survey, planning, and property data ship in this format. The built-in OSGB36 ↔ WGS84 conversion is accurate to within meters.
How can I tell which CRS a mystery coordinate uses?
Reference a known landmark. Tiananmen in WGS84 is roughly 116.397428, 39.90923. If the dataset shows that point near 116.40361, 39.91043 it is GCJ-02; near 116.41005, 39.91635 it is BD-09; if the values are 7+ digit numbers like 12958180, 4825923 it is Web Mercator or BD-09MC.
Related tools
After converting coordinates, continue with related normalization work in the Data category — units, number bases, and other format conversions.