Google Polyline Decoder

Decoding a polyline

Routing and mapping APIs return paths as a single encoded polyline string to save bandwidth. This tool turns that string back into the list of coordinates so you can plot, inspect or process the route yourself.

How it works

The decoder walks the string character by character. It subtracts 63 from each character, strips the continuation bit (0x20), and accumulates 5 bit chunks until a chunk without the continuation bit ends the value. That signed integer is the delta from the previous coordinate; it is un-shifted and inverted if odd to recover the sign.

_p~iF~ps|U_ulLnnqC_mqNvxq`@
  ->  38.5, -120.2 / 40.7, -120.95 / 43.252, -126.453

Latitude and longitude alternate, and each running total is divided by ten to the precision to produce the final coordinate.

Precision 5 vs precision 6

The encoded format does not carry the precision — the decoder has to be told. Google Maps and Google Directions API use precision 5, meaning each coordinate is multiplied by 1e5 before encoding (so a value accurate to about 1 metre at the equator). OSRM, Valhalla, and several other open-source routing engines use precision 6 (multiplied by 1e6), which gives roughly 10 cm accuracy. Decoding a precision-6 string with a precision-5 decoder shifts every point by a factor of 10, which usually lands the coordinates in the ocean or on a different continent — a quick way to spot the mismatch.

If you are unsure which precision an API returns, try precision 5 first and verify that at least the first decoded point looks plausible (roughly the right country).

What to do with the decoded coordinates

Once you have the lat/lng list, common next steps include:

• Plot on a map: paste into geojson.io or overpass-turbo to visualise the route immediately without writing any code.
• Calculate route length: sum the haversine distances between consecutive points to get total distance in metres.
• Sample the route: thin the point list to every N-th point for a lighter approximation.
• Convert to GeoJSON LineString: wrap the array in {"type":"LineString","coordinates":[[lng,lat],...]} (note GeoJSON is longitude-first).
• Feed into a post-processor: snap to roads, calculate elevation profiles, or compute turn-by-turn instructions.

Format details and edge cases

The encoded polyline uses only printable ASCII characters (codes 63–126), making it safe to embed in JSON strings, URLs, and HTML attributes without escaping. The format is inherently lossy — the precision of 5 or 6 decimal places limits coordinate accuracy — so decoding and re-encoding may produce a string that differs from the original by a unit in the least significant position. This is expected and harmless for routing and display purposes.

Debugging tips

If the decoded points do not make sense, work through these checks in order:

1. Wrong precision: the most common cause. Toggle between 5 and 6. A precision-5 string decoded at precision-6 produces coordinates roughly 10× too small (landing mid-ocean for typical lat/lng values).
2. Truncated string: the encoded polyline is sometimes cut off when pasted from a long URL or a JSON field. Each encoded character contributes 5 bits; a truncated string produces a valid-looking but short list, or an error at the last value. Check the full string length.
3. Escaped characters: some JSON serialisers escape the backslash character \ as \\. If the polyline contains \\ where \ is expected, strip the extra backslash before decoding.
4. Base64 confusion: encoded polylines are sometimes mistaken for base64 because both use mostly alphanumeric characters. They are different formats — do not base64-decode before passing to this tool.

The decoder reports an error for invalid characters or an incomplete value, so a clear error message usually points to one of these issues.