What the Geohash Encoder and Decoder does
Turn a latitude and longitude into a geohash at any precision from one to twelve characters, or paste a geohash and get the cell back: its centre, its bounding box, how big it is in metres at that latitude, and the eight neighbours around it. There is also a comparison that tells you how much of a prefix two hashes share, and what that does and does not prove.
A geohash is a string that encodes a rectangle rather than a point. Each character adds five bits, alternating between longitude and latitude, so every prefix of a hash is a bigger cell containing it - which is exactly why the format is useful as a database key, and exactly where it catches people out.
How to use it
- Enter a latitude and longitude and drag the precision slider. The hash, the cell size and the neighbour grid update as you move it.
- Or paste a geohash into the decode box. The coordinate fields fill in with the cell centre and everything below updates to describe that cell.
- Read the cell size before choosing a precision. Six characters is roughly 1.2 km by 0.6 km; nine characters is under five metres; twelve is centimetres, which is almost always more than the underlying position deserves.
- Use the comparison boxes to check two hashes against each other - the shared prefix, the distance between the centres, and the smallest cell that contains both.
- Export the cell as JSON, or as a GeoJSON polygon if you want to draw the rectangle somewhere.
Reading the results
The hash names a cell, not a point. The centre shown is the middle of that rectangle, and the error bars are half its height and half its width - so a five-character hash carries about two kilometres of uncertainty in each direction.
Odd-length hashes are wider than they are tall, even-length ones are close to square. That falls out of the bit interleaving: each character is five bits, so an odd number of characters gives longitude one bit more than latitude.
A shared prefix proves proximity; the absence of one proves nothing. Two points a metre apart on opposite sides of a cell boundary can differ from the very first character, which is why prefix matching alone is a poor proximity search without checking the neighbours too.
Cell widths shrink towards the poles with the cosine of latitude while heights stay constant. A six-character cell is about 1,222 m wide at the equator and about 611 m wide at sixty degrees north.
Worked example: the canonical hash u4pruydqqvj
Encoding 57.64911 N, 10.40744 E at eleven characters gives u4pruydqqvj, the example used in the original description of the scheme. Its five-character prefix, u4pru, is the cell that contains it - about 4.9 km square at the equator and about 2.6 km wide at this latitude, because 57.6 degrees north has a cosine of 0.536.
Decoding ezs42 gives a cell running from 42.583 to 42.627 degrees north and from -5.625 to -5.581 degrees east: five characters, twenty-five bits, twelve for latitude and thirteen for longitude. The centre is 42.605, -5.603, with error bars of about 0.022 and 0.022 degrees.
The third example encodes two points four ten-thousandths of a degree apart either side of -5.625, which is an exact cell boundary. The centres are metres apart, yet the hashes share only two characters - a clean demonstration that a short shared prefix is not a distance measurement.
Formulas and scoring rules
- Bit interleaving
bit 1 halves longitude, bit 2 halves latitude, alternating; every 5 bits become one base-32 characterAlphabet 0123456789bcdefghjkmnpqrstuvwxyz - a, i, l and o are omitted to reduce misreading.- Bits per axis
lonBits = ceil(5n / 2), latBits = floor(5n / 2) for n charactersLongitude gets the extra bit at odd lengths, which is why those cells are wider than tall.- Cell size in degrees
lonDeg = 360 / 2^lonBits, latDeg = 180 / 2^latBits- Cell size in metres
width = lonDeg x pi/180 x R x cos(latitude), height = latDeg x pi/180 x RR = 6,371,008.8 m, the WGS 84 mean radius. Width depends on latitude; height does not.- Centre and error
centre = (south + north)/2, (west + east)/2; error = (north - south)/2, (east - west)/2
Using geohashes for proximity search
The reason geohashes appear in databases is that a prefix query is an index scan: everything starting with u4pru lies inside one cell, so a single range lookup finds candidates without any geometry. It works well, provided you remember two things.
First, pick the precision to match the radius you want, using the cell-size table rather than a guess. Second, always query the eight neighbours as well as the centre cell, because a point just over a boundary has a different prefix and would otherwise be missed - which is precisely the failure the comparison box on this page demonstrates. Then filter the candidates by real distance, because a cell is a rectangle and a search radius is a circle.
Limitations: what the result does not prove
- A geohash is not a location; it is a rectangle. Quoting a twelve-character hash for a position that came from a phone implies centimetres of accuracy that the position never had.
- Prefix length is not a distance. Two nearby points can share nothing at all if a cell boundary runs between them, so proximity work must include the neighbours.
- Cells are not equal-area. They narrow towards the poles, so a fixed precision means a different ground area in Norway than in Kenya.
- This page does nothing with the coordinate beyond arithmetic. It does not look the position up, plot it on a basemap or check that it is on land.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- NGA - World Geodetic System 1984 (WGS 84) - checked 19 Sep 2026
- RFC 7946 - The GeoJSON Format
Frequently asked questions
How accurate is a geohash at each precision?
At the equator: one character is about 5,000 km, four is about 39 by 20 km, five about 4.9 km square, six about 1.2 by 0.6 km, seven about 153 by 152 m, eight about 38 by 19 m, and nine under five metres. Widths shrink with the cosine of latitude; the table on this page recalculates them for whatever latitude you are working at.
Why does the geohash alphabet skip a, i, l and o?
To stop characters being misread or mistyped: l against 1, o against 0, and i against both. The alphabet is 0-9 followed by b, c, d, e, f, g, h, j, k, m, n, p, q, r, s, t, u, v, w, x, y and z - thirty-two symbols, five bits each.
Do two geohashes that share a prefix mean the points are close?
Yes, in one direction only. A shared prefix of n characters means both points are inside the same cell at that precision, so they are within that cell's size of each other. The converse is false: points either side of a cell boundary can be metres apart and share nothing, which is why prefix searches must also check the neighbouring cells.
Why are some cells wider than they are tall?
Because each character carries five bits and the bits alternate between longitude and latitude. With an odd number of characters longitude has received one more bit than latitude, making the cell half as tall relative to its width. Even-length hashes come out roughly square at the equator.
What precision should I use for storing a phone's GPS position?
Seven or eight characters usually. A phone's outdoor accuracy is five to ten metres, and an eight-character cell is about 38 by 19 metres, so anything finer records precision the position never had. If the coordinate is sensitive, a shorter hash is also a deliberate way of coarsening it.
How are the neighbours of a geohash calculated?
From the alphabet itself, using the standard base-32 neighbour and border tables, so no coordinate arithmetic is involved and the result is exact. When a cell sits on the edge of its parent, the algorithm recurses into the parent, which is how neighbours work correctly across the antimeridian and near the poles.
Can I convert a geohash back to the exact original coordinate?
No, and that is by design. Encoding discards everything finer than the cell, so decoding returns the cell centre, not the point you started from. The error bars shown with the centre are the honest bounds of what the hash still knows.
Last reviewed by the A2Z.Tools team against the sources listed above.
