The Google Encoded Polyline format is a clever way to pack a long list of coordinates into a short string of printable characters. It is the format returned by the Google Directions and Roads APIs and accepted by the Static Maps API. This free tool encodes and decodes those strings in both directions, fully client-side.
Why this format exists
A raw list of GPS coordinates is verbose. A long driving route might contain hundreds of latitude-longitude pairs, each needing roughly 20 characters as decimal text. The encoded polyline format compresses this dramatically by storing only the difference from the previous point (deltas are small for smooth routes), then encoding those differences in a variable-length base-64-like scheme. The result is typically 3–5 times shorter than a plain coordinate list, which matters when embedding routes in URLs or API responses.
How it works
The algorithm encodes each coordinate as a signed offset from the previous one, so a smooth route compresses well:
- Multiply the latitude and longitude by
10^precision(usually 10^5) and round to an integer. - Take the difference from the previous point’s integer value.
- Left-shift the signed value by one bit; if the original was negative, invert all the bits (this is a one-bit zig-zag encoding of the sign).
- Break the result into 5-bit chunks, least significant first. Every chunk except the last is OR-ed with
0x20to flag “more chunks follow”. - Add 63 to each chunk and output it as an ASCII character.
Decoding reverses every step: read characters, subtract 63, strip the continuation bit, reassemble the 5-bit groups, undo the zig-zag, and accumulate the running latitude and longitude.
Tips and example
The two points 38.5,-120.2 and 40.7,-120.95 (precision 5) encode to the classic example string `_p~iF~ps|U_ulLnnqC from Google’s documentation.
- Match the precision on both ends. Google Directions uses 5; OSRM and some Roads responses use 6.
- Encoding rounds to your chosen precision, so a tiny round-trip difference is expected and harmless for maps.
- The longer your route, the bigger the win — deltas between nearby points use very few characters.
Common use cases
- Google Directions API: the
overview_polyline.pointsfield in a directions response is a precision-5 encoded polyline. Paste it into the decoder to extract all the waypoints. - Static Maps API: encode a route as a polyline string to embed it in a Static Maps image URL via the
path=enc:...parameter. - OSRM / Mapbox Directions: these services return precision-6 encoded polylines. Always set precision to 6 when decoding their responses, or every coordinate will be off by a factor of ten.
- GeoJSON conversion: decode the polyline into lat-lon pairs, then reformat as a GeoJSON LineString for use in mapping libraries like Leaflet or Mapbox GL.
- Route storage: storing a route as an encoded string uses a fraction of the space of a coordinate array in a database or URL query string.
Precision and accuracy
At precision 5 (the Google default), coordinates are stored to 5 decimal places, which is accurate to within about 1 metre — more than sufficient for road navigation. At precision 6 (OSRM default), accuracy improves to about 0.1 metre. The precision must match between encoder and decoder: decoding a precision-6 string at precision-5 produces coordinates ten times too large.
Everything runs in your browser — your route coordinates are never uploaded.