Geohash Encoder / Decoder

Field guide: Geohash Encoder / Decoder

A geohash packs a location into a short base-32 string — ttnfv2u is Delhi to ~76 m — by interleaving the bits of repeated longitude/latitude bisections. Its killer property is the prefix: truncate a geohash and you get the containing cell, which means a plain B-tree index, a Redis sorted set or a DynamoDB partition key can answer 'what's near me' queries with string prefix matching. That's why Elasticsearch, Redis geo commands and half the location startups of the last decade use it under the hood. This tool encodes and decodes interactively, with a live table of what each length means in metres.

The encoder implements Gustavo Niemeyer's original public-domain scheme (the one every library is compatible with): base-32 alphabet 0–9 b–z minus a, i, l, o; even bits longitude, odd bits latitude. Decoding returns the cell centre with its ± error, which is the honest way to state geohash precision — a 5-character hash isn't a point, it's a ~4.9 × 4.9 km box. Everything runs client-side, so coordinates you test never leave the browser.

Field tips

• Choosing a length for proximity features: 6 characters (~±0.6 km) for neighbourhood grouping, 7 (~±76 m) for street-level, 9 (~±2.4 m) for door-level. Longer than 9 exceeds consumer GPS accuracy.
• Prefix search has a gotcha: two points metres apart can have completely different geohashes across cell boundaries (the 'edge problem'). Production proximity queries check the cell and its 8 neighbours.
• Geohash cells aren't square away from the equator — east-west size shrinks with cos(latitude), so the same length is 'tighter' in Helsinki than in Singapore.

Conversions run locally in your browser and follow the cited specifications. Always verify critical output in the target application; for survey-grade or legal data, confirm coordinate systems and datums with your GIS team.