Encoded polyline converter

What this tool does

The encoded polyline format stores a series of coordinates as differences, scaled by a power of ten and packed into printable ASCII, five bits at a time. The result is roughly a third the size of the equivalent JSON — which is why every routing API uses it, and why you keep meeting these strings without a map to put them on.

Decoding gives you a LineString (or a Point when the string holds a single position) as GeoJSON. Encoding goes the other way, turning line, polygon-ring, or point geometries back into strings — one per line, so a file with several lines produces several polylines.

How this tool works

The algorithm, in both directions.

1. Decode

Each line of input is decoded independently. Values are read five bits at a time from the character codes, reassembled, zig-zag decoded back into signed integers, accumulated as differences from the previous point, and divided by 10^precision. Coordinates come out in GeoJSON order — longitude, latitude — even though the format itself stores latitude first.

2. Encode

Paste GeoJSON instead and switch the direction. Every LineString becomes one polyline; a MultiLineString and a Polygon produce one per part or ring; a Point becomes a single-position string. Coordinates are rounded to the precision you set, so encoding is lossy by exactly that amount — 5 decimals is about 1 m.

3. Wrap

Decoded output is a FeatureCollection by default, which drops straight into the viewer or any map library. Choose bare geometry for a single decoded line when you want to paste the geometry alone into a request body.

Options

Precision

This is the setting that catches everyone. Google's Directions API and Maps URLs use precision 5; OSRM v5, Valhalla and Mapbox's newer APIs default to 6. Decode with the wrong one and your route lands in the wrong place — off by a factor of ten, which usually means somewhere in the ocean.

Direction

polyline → GeoJSON reads one string per line, so you can decode a whole column of routes at once. GeoJSON → polyline expects a document in the input pane and writes one encoded string per geometry.

Example

Input (precision 5):

_p~iF~ps|U_ulLnnqC_mqNvxq`@

Output:

{
  "type": "FeatureCollection",
  "features": [
    { "type": "Feature", "properties": {},
      "geometry": { "type": "LineString",
        "coordinates": [[-120.2, 38.5], [-120.95, 40.7], [-126.453, 43.252]] } }
  ]
}

This is the example string from Google's own documentation. Note the coordinate order flip: the format stores latitude first, GeoJSON stores longitude first, and the conversion handles it — a frequent source of hand-rolled bugs.

Tips & common pitfalls

• Wrong precision is the number-one failure. If a decoded route is a tiny squiggle near 0°,0° or shoots off the map, switch between 5 and 6 and try again.
• Escaping bites in JSON. Polyline strings contain backslashes. When a string is embedded in JSON, each backslash is doubled — unescape it before pasting, or the decode produces garbage.
• Encoding is lossy. Coordinates are rounded to the chosen precision, so a round trip does not return byte-identical numbers. At precision 5 the error is about a metre.
• Only the line is encoded. Properties, elevation and timestamps have no place in the format. Keep the GeoJSON if you need them.

FAQ

Which precision does my API use?

Google Directions, Maps URLs and the Roads API use 5. OSRM v5, Valhalla, and Mapbox Directions default to 6 (OSRM can be configured either way). If in doubt, decode with both and see which lands on land.

Can it decode several polylines at once?

Yes — one string per line. Each becomes its own feature, so a column of routes from a spreadsheet converts in one go.

Does it handle polygons?

When encoding, each polygon ring becomes its own polyline string. When decoding, you get a LineString; close it into a polygon yourself if that is what the data means.

Is my route data uploaded?

No. Both directions run in your browser.