A GeoHash is a short string that represents a latitude/longitude location by encoding a rectangular area on Earth's surface. It was invented by Gustavo Niemeyer in 2008 as a simple, URL-safe way to share and index locations. Each character in the string subdivides the area it represents into 32 smaller cells, so adding characters increases precision. A 5-character geohash points to an area of roughly 5 km, while a 9-character geohash narrows that down to a few meters — fine enough for a specific building.

GeoHashes are compact and human-readable, which makes them useful for URLs, database indexes, cache keys, and tag systems. Because nearby locations share a common prefix, you can do fast proximity queries with simple string comparisons: all locations starting with 'u4pruyd' fall inside a small common bounding box. Many databases including Redis, Elasticsearch, and MongoDB support GeoHash indexing natively for fast geospatial search without heavy spatial indexes.

How precise is each GeoHash length?

Each character adds roughly a factor of 4 to 5 in precision along both axes. Approximate cell sizes by length: 1 character ≈ 5000 km, 2 ≈ 1250 km, 3 ≈ 156 km, 4 ≈ 39 km, 5 ≈ 4.9 km, 6 ≈ 1.2 km, 7 ≈ 153 m, 8 ≈ 38 m, 9 ≈ 4.8 m, 10 ≈ 1.2 m, 11 ≈ 15 cm, 12 ≈ 3.7 cm. The east-west span changes with latitude because meridians converge at the poles, so actual cells are slightly rectangular rather than square.

GeoHash Encoder and Decoder - Convert Lat/Lon to GeoHash

Q: What characters can appear in a GeoHash?

The GeoHash alphabet is a 32-character base-32 encoding that excludes visually ambiguous letters: '0123456789bcdefghjkmnpqrstuvwxyz'. The letters 'a', 'i', 'l', and 'o' are omitted to avoid confusion with digits and other letters. GeoHashes are case-insensitive — all uppercase is treated the same as all lowercase — but the canonical form is lowercase.

Q: What happens at cell boundaries?

Adjacent locations on opposite sides of a cell boundary can have very different geohashes that do not share a long prefix. This is a known limitation: two points can be a few meters apart but fall into different cells that share only a short prefix. For robust proximity search that avoids boundary artifacts, query the geohash of the point and the eight neighbor cells as well. Many geohash libraries provide a 'neighbors' function for exactly this reason.

Encode a latitude/longitude pair into a GeoHash string, or decode a GeoHash back to coordinates and a bounding box. Precision is adjustable from 1 to 12 characters.

How to Use the GeoHash Encoder/Decoder

Switch between Encode and Decode at the top. In Encode mode, enter a latitude, longitude, and desired precision (1 to 12 characters), and the tool returns the corresponding GeoHash string. In Decode mode, paste a GeoHash and the tool returns the center coordinate of the cell along with the error margin, which tells you how big the bounding box is at that precision. The default example encodes New York City's coordinates at precision 9, which narrows the location down to an area about 5 meters across.

How GeoHashes Work Under the Hood

A GeoHash is produced by interleaving bits of the longitude and latitude after recursively halving the globe. Each step splits either the longitude range or the latitude range in half, records a 0 or 1 depending on which side the point falls, and continues until enough bits have been collected for the requested precision. The bit stream is then grouped into 5-bit chunks and encoded using a custom base-32 alphabet that excludes visually ambiguous characters. This produces a short string that is stable, deterministic, and that shares a prefix with neighboring locations — the property that makes GeoHashes useful for indexing and range queries.

When to Use GeoHashes in Your Application

GeoHashes shine in any system that needs compact geographic identifiers. Use them as cache keys for geospatial data so that nearby queries share a cache entry. Store them in database indexes for fast prefix-based range queries — all documents whose geohash starts with 'dr5r' fall into the same rough region. Use them as URL parameters to identify a place without exposing exact coordinates, which is useful for privacy. Use them as tile identifiers in custom map systems. And use them in distributed systems as deterministic sharding keys for geographic data partitioning.

Limitations to Keep in Mind

GeoHashes are not a perfect representation of nearness. Two points that are a few meters apart can fall on opposite sides of a cell boundary, producing geohashes that share only a short prefix. To avoid missing close neighbors, query the geohash of your point along with the eight neighboring cells. GeoHashes also distort at high latitudes because longitude cells shrink with the cosine of latitude — a precision-5 cell near the equator is much wider east-to-west than the same precision cell near the poles. And GeoHashes are tied to a rectangular lat/lon grid, which does not align well with administrative boundaries, so they are not a substitute for proper polygon-based geofencing.

Frequently Asked Questions

What is a GeoHash?

A short URL-safe string that encodes a latitude/longitude into a rectangular cell on the Earth. Longer strings mean smaller cells and higher precision.

Why use GeoHashes?

They are compact, human-readable, and enable prefix-based proximity queries in databases and caches without requiring full geospatial indexes.

How precise is each length?

Roughly: 5 chars ≈ 5 km, 7 chars ≈ 150 m, 9 chars ≈ 5 m, 12 chars ≈ 4 cm. Each additional character shrinks the cell by about 4–5×.

What characters can appear in a GeoHash?

The 32-character alphabet "0123456789bcdefghjkmnpqrstuvwxyz". The letters a, i, l, and o are excluded to avoid confusion with digits.

What happens at cell boundaries?

Neighbors on opposite sides of a cell edge can have very different geohashes. Query the point plus its eight neighbors for robust proximity search.

GeoHash Encoder and Decoder

Result