Coordinate Converter (WGS84 / GCJ-02 / BD-09)

Features

• All three coordinates at once — WGS84, GCJ-02 and BD-09 — and any of them can be the input
• Reports the straight-line distance from your input in metres, so the offset is visible
• GCJ-02 to WGS84 uses an iterative inverse, accurate to 1e-9 degrees (about 0.1 mm)
• Points outside China are labelled as such, so three identical rows read as correct rather than broken
• Input order can be "latitude, longitude" or "longitude, latitude"; a swapped pair is called out as an ordering problem
• Commas, spaces and semicolons all separate; full-width commas and spaces are normalised
• ⚠️ Degrees-minutes-seconds can be pasted straight in: `39°54′31.4″N 116°23′51.0″E`, `39d54m31.4sN`, `N39°54′31.4″`, and even decimal degrees with a hemisphere suffix (`39.908722N`). Minutes or seconds of 60 or more are rejected outright rather than turned into a plausible-looking coordinate
• Also gives degrees-minutes-seconds (39°54′31.40″N 116°23′51.00″E), one row per coordinate system
• Gives the Open Location Code (full Plus Code) — an address people can read aloud without a street number
• Enter two lines and you also get the great-circle distance and initial bearing between the points (Beijing to Shanghai: 1068.3 km), with the distance in kilometres, statute miles and nautical miles
• ⚠️ The distance uses a spherical formula, and the result says how far that is from the ellipsoidal geodesic — kilometres over long distances
• Ready-to-open map links for OpenStreetMap, Google Maps, Amap, Baidu Maps and Bing
• ⚠️ Each link uses its own coordinate system: OSM / Google / Bing take WGS84, Amap takes GCJ-02, Baidu takes BD-09 — pasting WGS84 into a Baidu link lands hundreds of metres away
• ⚠️ Each link states its system and parameter order: Amap takes "longitude, latitude", the opposite of the rest (reversing them lands you on another continent)
• Zoom selectable from World / Country / City / Street / Building, applied to the OSM and Bing links
• Adjustable decimal places, defaulting to six (about 0.1 m), matching the usual map pickers
• Every row can be copied on its own, and annotations such as "(input)" stay out of the copied text
• Everything runs locally in the browser; coordinates are never uploaded

How to use

1. Pick which system your input uses
2. Pick the order your data is in — latitude first or longitude first
3. Paste the coordinate
4. All three appear as you type; copy any row on its own

FAQ

How is degrees-minutes-seconds computed? Can it show 60 seconds?

The fractional part of the decimal degree is multiplied by 60 for minutes, and what remains by 60 for seconds, rounded to two decimal places (about 3 mm, ample for any surveying form). That rounding creates one boundary that has to be handled: `39.9999999` rounds its seconds to `60.00`, and writing that out gives `39°59′60.00″` — a value that does not exist. So 60 seconds carries into minutes, and 60 minutes carries into degrees, giving `40°00′00.00″`. A test sweeps a run of boundary values for this.

Why are the three outputs identical outside China?

Because the GCJ-02 offset is only applied inside China — that is part of the algorithm, not something missing here. For a point outside the country, WGS84 and GCJ-02 are the same value by definition. BD-09 is different: Baidu applies its layer everywhere, so a point abroad still gets a BD-09 value unlike the other two. A line in the output says so explicitly.

What is a Plus Code, and how is it different from coordinates?

An Open Location Code (Google’s open location encoding) turns a patch of ground into a few letters and digits — Tiananmen Square is `8PFRW95W+FX`. Its purpose differs from coordinates: coordinates are for machines, a Plus Code is for saying out loud. Plenty of places have no house number and no formal address, and a string of coordinates gets misheard; `8PFRW95W+FX` is short enough to read over the phone. ⚠️ Two things to know: it names an area, not a point (a 10-digit code is about 14 m across, and anywhere inside encodes to the same code); and short codes — the ones with leading digits omitted — need a reference location to be resolved, which different maps choose differently. So this tool only emits full codes, and never guesses the reference.

Why does the distance differ from my map app by a few kilometres?

Because this uses a spherical formula (the Earth as a sphere of radius 6371.0088 km) while map apps follow the geodesic on the WGS84 ellipsoid. The Earth is flattened, and over medium to long distances that is a few parts in a thousand — Beijing to Shanghai is about 1068 km and comes out a few kilometres apart. For “roughly how far” it is fine; for measurements accurate to the metre, use GIS software. The bearing is the same story, and it only describes the heading as you leave: along a great circle the bearing changes continuously.

How do the three systems relate?

WGS84 is the international standard and what a GPS chip reports. GCJ-02 is a nonlinear offset applied to WGS84 by Chinese mapping authorities, used by Amap, Tencent and Google inside mainland China so that published coordinates do not match the true ones. BD-09 is a further offset Baidu applies on top of GCJ-02, so Baidu takes two conversions from either of the others. Hong Kong, Macau, Taiwan and some border areas are treated differently by different vendors; this tool uses the common rectangular test.

Why is the input order a separate option?

Because Google Maps copies coordinates as "latitude, longitude" while the Amap and Baidu pickers give "longitude, latitude" — both numbers are similar-looking decimals, so the eye cannot tell which is which. Guessing wrong does not shift you a few hundred metres; it shifts you hundreds of kilometres (a latitude of 39.9 read as a longitude lands in Central Asia). So nothing is guessed: the order is a choice, and when the latitude is beyond ±90 the message names the ordering as the likely cause instead of just reporting a range error.

Why do the map links use different coordinates, and why would a link point to the wrong place?

Because the services use different systems: OpenStreetMap, Google and Bing use WGS84, Amap uses GCJ-02 and Baidu uses BD-09 — the same building is three different numbers, hundreds of metres apart. So each link is built from its own converted coordinate rather than one coordinate reused everywhere (the usual bug in tools like this, and it shows up as "the map pinned the wrong spot"). ⚠️ The parameter order differs too: Amap takes `position=longitude,latitude` (longitude first) while the rest put latitude first — reversing them does not shift you a few hundred metres, it lands you on another continent. Each link states its system and order on the left.

How accurate is the conversion?

Between GCJ-02 and WGS84 the forward transform is closed-form and the inverse iterates to 1e-9 degrees (about 0.1 mm). The BD-09 pair is an approximate inverse: the reverse formula substitutes the converted values for the originals when computing two tiny perturbations, leaving a round-trip residual around 1e-7 degrees (about 4 cm). That is far below any practical need, but it is not an exact inverse, so the accuracy claim here says so. Vendor offsets also vary slightly near borders; metre-level differences are normal in this domain.

Are my coordinates uploaded?

No. All three conversions run in browser memory; the page makes no requests and works offline. Coordinates often point at a specific home or job site, and none of it leaves your device.