Geohash Encoder & Decoder
Private by design — runs entirely in your browser
Switch to encode mode and enter latitude and longitude (with a precision slider) to get a geohash string. Switch to decode mode and paste a hash to see the center coordinates and the southwest/northeast bounds of its cell. Useful for spatial indexes, proximity searches, and pseudonymized location storage.
What a geohash actually encodes
A geohash interleaves the bits of longitude and latitude, then encodes the result in base32 with a custom alphabet (0-9 plus b-z without a/i/l/o). Each character carries 5 bits of precision, alternating between longitude and latitude refinement. The result is a short, URL-safe string whose prefix relationship maps directly to spatial containment: any geohash that starts with "dr5ru" sits inside the cell named dr5ru.
Precision and cell size
At precision 1 the world is divided into 32 cells, each about 5000 km wide. Precision 5 (≈ 4.9 km square at the equator) is right for neighborhood-level grouping. Precision 9 (≈ 5 m square) is the right granularity for a single building. Precision 12 reaches roughly 4 cm but is rarely needed outside of survey-grade work. Cells shrink as you go toward the poles.
Why use geohashes
String prefixes index well in PostgreSQL, Redis, DynamoDB, and SQLite. To find points within 5 km of a target, compute the target geohash at precision 5, then index for prefix matches — much cheaper than great-circle distance queries. The cell-boundary edge case is real, so most pipelines also query the eight neighboring cells. Geohash predates S2 and H3 by a decade and remains the simplest indexing scheme for hot-path proximity workloads.
Frequently Asked Questions
- Why does precision 5 cover a whole city?
- Each character carries 5 bits, so precision 5 = 25 bits = roughly 4.9 km × 4.9 km cells near the equator. Cities of a few kilometers across fit inside one cell, which is why so many ride-hailing and food-delivery apps bucket riders/orders by precision-5 geohash for fast matching.
- Two close points end up with different geohashes — bug?
- Not a bug, an artifact of grid cells. Points across a cell boundary share no common prefix even if they are 1 m apart. Production code usually queries the target hash plus its eight neighbors (a 3×3 cell ring) for proximity searches.
- What is the alphabet used in geohash?
- 0-9 plus b-z without a, i, l, o. The deliberate exclusion of a/i/l/o avoids confusion with 0/1 in low-contrast fonts. The encoding is base32 over this custom alphabet — different from RFC 4648 base32.
- How does geohash compare with S2 and H3?
- Geohash is the simplest and oldest of the three. S2 and H3 use spherical or hexagonal grids that handle pole distortion better. For most app-level proximity workloads geohash is enough; for navigation and routing at planetary scale, S2/H3 pay off.
- Can geohashes be safely indexed in PostgreSQL?
- Yes. Treat the hash as a text column with a btree index, and prefix searches (LIKE 'dr5ru%') become very fast. For spatial queries you can complement with PostGIS, but plain prefix matching covers most use cases.
- Does Toova log the coordinates I encode?
- No. Encoding and decoding run in JavaScript on this page. The coordinates and the resulting hash never reach a Toova server.