How a geohash works
A geohash turns a latitude and longitude into a string such as ezs42. The string does not name a point. It names a rectangular cell, and every point inside that cell has the same geohash at that length. The encoding was originally described by Gustavo Niemeyer.
Each character narrows the area. At each level, as Chris Veness explains, every extra character identifies one of 32 sub-cells of the cell before it. So a one-character geohash covers a huge area, and each character added after that shrinks the cell.
Two properties follow, and they make geohashes useful in databases:
- Truncation keeps the area. The Redis documentation notes that a geohash can be shortened by removing characters from the right: it loses precision but still points to the same area.
- Prefixes group nearby places. PostGIS describes a geohash as a text form that is sortable and searchable by prefix, so a query for every string starting with a given prefix returns everything in that cell.
The Geohash Python module shows the length at work: the point at latitude 42.6, longitude -5.6 encodes to ezs42e44yx96 at full length, and to ezs42 when you ask for precision 5.
Precision and cell size
How large a cell is depends on the length of the geohash and on latitude, because cells narrow towards the poles. The Elasticsearch reference gives the cell dimensions at the equator, the widest case:
| Geohash length | Cell width x height at the equator |
|---|---|
| 1 | 5,009.4 km x 4,992.6 km |
| 2 | 1,252.3 km x 624.1 km |
| 3 | 156.5 km x 156 km |
| 4 | 39.1 km x 19.5 km |
| 5 | 4.9 km x 4.9 km |
| 6 | 1.2 km x 609.4 m |
| 7 | 152.9 m x 152.4 m |
| 8 | 38.2 m x 19 m |
Elasticsearch accepts lengths from 1 to 12, and notes that a length-12 geohash covers less than a square metre. Veness’s page gives the same sizes rounded, and points out that cell width shrinks to zero at the poles.
Choosing a length is a trade between detail and disclosure. A five-character geohash places something within a cell a few kilometres across; an eight-character one narrows it to a few tens of metres.
Nearby places and prefixes
Shared prefixes mean shared cells, so places with the same long prefix are close together. The reverse is not true. The Redis documentation warns that strings with different prefixes can still be nearby, and Veness gives an example from France: La Roche-Chalais, in cell u000, is just 30 km from Pomerol, in cell ezzz, because the two sit on either side of a large cell boundary.
The fix is to search neighbours as well. Veness suggests that a reliable proximity search also checks the prefixes of a cell’s eight neighbouring cells, not just the cell itself.
Where geohashes are used
- Spatial indexes and aggregations. Elasticsearch groups points into geohash grid buckets of a chosen precision, and Redis returns standard geohash strings for members of its geospatial index.
- Database functions. PostGIS’s
ST_GeoHashreturns the geohash for a geometry, with an optional maximum number of characters. - Sharing a place. Veness notes that a geohash might be easier to read out than a pair of coordinates.
- Coarsening a location. Truncating a geohash is a simple way to record an area rather than a point, which matters when a location record can reveal more than intended.
Offline Protocol’s Proof of Location is one example of the last use. Its backend commits a precision-5 geohash, approximately a 5 km cell, of a claimed location to an EigenLayer AVS contract on the Ethereum Sepolia testnet, and that geohash and each task’s time remain public there.
Limits
- Cells are not equal in area. Width shrinks away from the equator, so the same length covers less ground near the poles.
- Boundaries split neighbours. Two points metres apart can fall into different cells with different prefixes.
- It is not secret. A geohash is an encoding that anyone can decode. A coarse geohash reveals less, but what it does reveal is readable by everyone who sees it, and over many records even coarse cells can trace a pattern.