GCJ-02 to WGS84

LongitudeLatitude

GCJ02

Longitude

116.413642

Latitude

39.905603

Spherical distance from the input: 555 m

A public approximation. Not traffic, routing, or a survey. Copy order is latitude, longitude.

How it works

A phone GPS chip usually speaks WGS84. Amap and Tencent draw on GCJ-02, the offset system often called Mars coordinates. Baidu draws on BD-09, which is a further shift on top of GCJ-02. Drop a WGS84 point straight onto a GCJ-02 map and it can sit hundreds of meters away, on the wrong side of a street. This page runs one pair of numbers through the public polynomial that open-source libraries use for that offset, and through the usual BD-09 polar shift. It does not fetch traffic, snap to a road, or claim the marker will land on the correct lane.

WGS84 to GCJ-02 is evaluated relative to 105° E, 35° N. The offsets are sine polynomials, then scaled with the Krasovsky ellipsoid used by this approximation: semi-major axis 6378245 m and eccentricity squared 0.00669342162296594323. If longitude is outside 72.004 to 137.8347, or latitude is outside 0.8293 to 55.8271, that step returns the input unchanged. GCJ-02 back to WGS84 is not an algebraic inverse. The page runs the forward function once and reflects: output = 2 × input − forward(input). GCJ-02 and BD-09 use a polar shift of about 0.0065° in longitude and 0.006° in latitude, and that pair of formulas does not test whether the point is inside China. Results are shown to six decimal places.

How far the Beijing sample actually moves

WGS84 longitude 116.4074 and latitude 39.9042, a point in central Beijing, becomes GCJ-02 116.413642, 39.905603. The same point becomes BD-09 116.420046, 39.911865. On a sphere of radius 6378137 m the WGS84 point and the GCJ-02 point are about 555 m apart. Six decimal places in latitude are about 0.11 m, which is finer than this model and finer than a hand-held GPS. The page prints six places so you can compare with other implementations of the same polynomial. It is not a surveyed coordinate.

Reflecting that GCJ-02 point back toward WGS84 yields 116.407403, 39.904202. The residual against the start is about 0.000003° in each axis. That is the one-step approximation, not a proof that a vendor’s closed algorithm is reversible. Outside the bounding box the WGS84/GCJ-02 pair is a copy: Tokyo at 139.6917, 35.6895 comes back unchanged because the longitude is past 137.8347. BD-09 still shifts a point outside that box, because its formulas have no such test. Do not “correct” a Paris coordinate into BD-09 and expect it to stay put.

What you should not expect

This is the widely copied public approximation, not a certified reproduction of a private map build, and not a statement of Chinese surveying law. Two apps can both say GCJ-02 and still differ by a few meters after a tile update. The page will not route you, estimate travel time, or show congestion. If you need a lane, a parcel boundary, or an engineering stake, use the control your surveyor names. If you only need a photo pin from a GPS track to sit on an Amap basemap, WGS84 to GCJ-02 is the conversion people mean, and the residual above is the size of the reverse error on this sample.

The copy button writes latitude, then longitude. The boxes on screen are longitude, then latitude. Pasting the copied line back into the boxes in the same order swaps the axes and sends the point somewhere else. East longitude and north latitude are positive. A minus sign is a hemisphere change, not a decoration.

Worked examples

Input: WGS84 to GCJ-02, longitude 116.4074, latitude 39.9042
Output: 116.413642, 39.905603, about 555 m away on the 6378137 m sphere
Input: The same WGS84 point to BD-09
Output: 116.420046, 39.911865
Input: WGS84 to GCJ-02, Tokyo 139.6917, 35.6895
Output: 139.691700, 35.689500. The values do not change

Limits

The reverse step leaves a residual. The Beijing GCJ-02 point converts back to 116.407403, 39.904202.
The copy button order is latitude, longitude. The form is longitude, latitude.
The meter figure is a spherical distance, not a geodesic on the ellipsoid used inside the offset.

Common mistakes

Converting a point that is already GCJ-02 as if it were WGS84. The offset is applied twice.
Running GCJ-02 to BD-09 on a point outside China and expecting the China bounding box to protect you. It does not apply to that pair.
Promising that the converted pin matches live traffic or a driving lane. The page never sees a road network.

Questions

Which system does each map use?▾

GPS chips and most maps outside China use WGS84. Amap and Tencent use GCJ-02. Baidu uses BD-09. From a GPS track to Amap, choose WGS84 to GCJ-02. From Amap to Baidu, choose GCJ-02 to BD-09.

Why is the reverse not exact?▾

The page reflects one forward evaluation. It does not solve the polynomial. On the Beijing sample the residual is about 0.000003°.

Can I upload a track?▾

No. One pair at a time. There is no traffic layer and no route.

Sources

Constants in this implementation: Krasovsky a = 6378245 m, ee = 0.00669342162296594323, evaluation origin 105° E and 35° N, and the bounding box 72.004–137.8347° E, 0.8293–55.8271° N.
BD-09 shift used here: about +0.0065° longitude and +0.006° latitude in the forward GCJ-02 to BD-09 polar step. It is a public approximation, not a Baidu-certified API.