More games at WuGames.ioSponsoredDiscover free browser games — play instantly, no download, no sign-up.Play
Converter Tools ConverterGenerator Tools GeneratorGeo Tools Geo

Geohash Encoder Decoder - Grid Cell System

Free Geohash tool: encode/decode geohash codes, view grid cells with real cell size, find 8 neighbors, copy 9-cell CSV for proximity queries. Use my location.

What is Geohash?

Geohash is a geocoding system that encodes geographic coordinates (latitude/longitude) into a short alphanumeric string. Developed by Gustavo Niemeyer in 2008, it divides the world into a hierarchical grid where each character adds precision to the location.

A geohash like 'w7p9v0rr' represents a specific rectangular area on Earth. The longer the geohash, the smaller and more precise the area. This makes geohash perfect for proximity searches, spatial indexing, and location-based queries in databases.

Key features of Geohash:

  • Hierarchical structure: Longer strings represent smaller areas within larger ones
  • Proximity property: Similar geohashes are geographically close (with some exceptions)
  • Easy to use: Simple string comparison for rough proximity checks
  • Database friendly: Can be indexed as strings for fast spatial queries
  • URL safe: Uses base-32 characters (0-9, a-z excluding a, i, l, o)

Geohash is widely used in location-based services, NoSQL databases (MongoDB, Redis), and mapping applications for efficient spatial data management.

How Geohash Works

Geohash uses a base-32 encoding system that progressively divides the Earth into smaller rectangular cells. Each character in the geohash string represents one step in this hierarchical subdivision:

Precision levels and cell sizes:

  • 1 character: ~5,000km × 5,000km (continental level)
  • 3 characters: ~156km × 156km (city level)
  • 5 characters: ~5km × 5km (neighborhood)
  • 7 characters: ~150m × 150m (street level)
  • 9 characters: ~5m × 5m (building level)
  • 12 characters: ~4cm × 2cm (sub-meter precision)

Encoding process:

The algorithm alternates between longitude and latitude bits, dividing the coordinate space in half with each bit. Every 5 bits are encoded as a single base-32 character, building the geohash string from left to right.

Neighbor finding:

Geohash provides efficient neighbor lookup by calculating adjacent grid cells. This is useful for 'find nearby locations' queries, though boundary cases require special handling.

Use Cases for Geohash

Geohash is essential in various location-based applications:

  • Proximity Search: Find nearby points of interest within a geohash prefix
  • Spatial Indexing: Organize location data in databases for fast queries
  • Clustering: Group nearby locations by truncating geohash precision
  • Caching: Use geohash as cache keys for location-based data
  • URL Shortening: Share approximate locations in short URLs
  • Database Sharding: Distribute location data across servers by geohash prefix

Geohash vs Other Systems

Comparing Geohash with other geocoding systems:

  • Geohash vs Lat/Lon: More compact, easier to search by prefix, but less precise
  • Geohash vs QuadKeys: Similar concept, but different encoding (base-32 vs base-4)
  • Geohash vs Plus Codes: Geohash uses variable precision, Plus Codes have fixed format
  • Geohash vs H3: H3 uses hexagons (better shape), geohash uses rectangles (simpler)

Choose geohash for database indexing and prefix-based proximity searches. Use other systems when you need human-readable codes (Plus Codes) or better spatial properties (H3).

Working with Neighbors

Geohash provides 8 neighboring cells (N, NE, E, SE, S, SW, W, NW) for each location. This is useful for expanding search areas:

  • Simple proximity: Query the main geohash and its 8 neighbors (9 cells total)
  • Edge cases: Locations near cell boundaries may require neighbor checks
  • Radius search: Use multiple precision levels and neighbors for circular areas
  • Real-time updates: Monitor geohash changes as objects move between cells

Note that geohash neighbors don't perfectly handle all edge cases (especially at longitude boundaries), so distance calculations may still be needed for precise proximity queries.

About Geohash Encoder Decoder - Grid Cell System

Geohash Encoder Decoder turns latitude/longitude into the short alphanumeric strings ("w7p9v0rr") used by Redis GEO, MongoDB, Cassandra, and other databases for fast proximity queries. Encode a point at precision 1-12 to get the geohash plus its bounding box, cell size, and 8 neighbouring cells (the famous 9-cell proximity coverage), or decode an existing geohash back to coordinates. Built for backend engineers building 'find nearby' features, data engineers indexing IoT telemetry, ride-share and delivery platforms sharding location data by prefix, and anyone exploring spatial indexing. Copy all 9 cells as CSV for direct use in SQL WHERE clauses. Try also our Distance Bearing and GeoJSON Validator.

Frequently Asked Questions

Geohash is a hierarchical spatial indexing system invented by Gustavo Niemeyer in 2008 that encodes a latitude-longitude pair into a short alphanumeric string like "u4pruydqqvj". Each additional character roughly multiplies precision by 32 — 5 chars ≈ ±2.4 km, 7 chars ≈ ±76 m, 9 chars ≈ ±2.4 m, 11 chars ≈ ±7 cm. Strings that share a prefix represent nearby locations, which makes geohash extremely useful for spatial database indexing (Redis GEOADD, MongoDB 2dsphere, Cassandra), proximity queries, deduplication of nearby GPS points, and URL-friendly location sharing. The downside: cells are not square (they're 2× taller than wide at certain levels) and proximity-by-prefix breaks at cell boundaries — two points 1 meter apart can have different prefixes if they straddle a geohash boundary.

Geohash divides Earth recursively into 32-cell grids (using base-32 with the alphabet 0123456789bcdefghjkmnpqrstuvwxyz — note no a, i, l, o to avoid visual confusion). Each character adds 5 bits, alternating between longitude and latitude refinement, so cell dimensions alternate between 2:1 and 1:1 aspect ratios. Approximate cell sizes at the equator: length 1 = 5,000 × 5,000 km, length 2 = 1,250 × 625 km, length 3 = 156 × 156 km, length 4 = 39 × 19.5 km, length 5 = 4.9 × 4.9 km, length 6 = 1.2 × 0.61 km, length 7 = 153 × 153 m, length 8 = 38.2 × 19.1 m, length 9 = 4.8 × 4.8 m, length 10 = 1.2 × 0.6 m, length 11 = 15 × 15 cm, length 12 = 3.7 × 1.8 cm. Cell sizes shrink with cosine of latitude in the longitude dimension.

This is the famous "edge effect." Two points 1 meter apart can land in different cells if a geohash boundary runs between them — and adjacent cells often share only a 1-character prefix or none at all. The worst case is at the equator and prime meridian, where the four quadrants (north/south and east/west) all begin with different characters (s, t, e, k or similar). Production systems work around this by querying not just your geohash but also its 8 neighbors (north, south, east, west, and four diagonals), then filtering by exact distance. Libraries like `geohash-neighbours` or `nodejs-geohash` give you the 8 neighbors directly. The same fix applies to Z-order curves and Hilbert curves — any 1D space-filling curve has this discontinuity problem.

Four modern spatial indexes solve overlapping problems differently. Geohash (Niemeyer 2008): base-32 string, rectangular cells, prefix-based proximity, simple and ubiquitous, edge-effect issues. Plus Codes / Open Location Code (Google 2015): designed for human use, area-code-like format "6PR599X8+8H", baked into Google Maps, doesn't require a country reference. H3 (Uber 2018): hexagonal cells of 16 resolutions, uniform neighbor distance (always 6 neighbors), excellent for ride-share matching and flow analytics, 64-bit integer or string output. S2 (Google, used in BigQuery and Bing): hierarchical Hilbert-curve cells on a sphere, 30 levels, cells are approximately equal-area squares, used in YouTube/Google for spatial queries. Geohash for simple key-value sharding, H3 for analytics, S2 for global indexing, Plus Codes for addressing — pick by use case.

A quadkey is the indexing scheme behind Microsoft's Bing Maps and most Web Mercator tile servers. Each level subdivides the world into 4 quadrants (Q1-Q4) numbered 0-3, so a quadkey is a string of 0-3 digits like "02313011120". Geohash uses base-32 (5 bits per character) and alternates lat/lng refinement; quadkey uses base-4 (2 bits per character) and applies both simultaneously, giving square cells in Web Mercator projection. Conversion: 1 geohash character = 2.5 quadkey characters (5 bits ÷ 2 bits). Quadkeys map directly to map tiles at zoom levels 1-23 (zoom = quadkey length), which is why every web map tile URL has that structure. Geohash is purely a coordinate encoding with no tile-server relationship. Both share the property that prefix = ancestor cell.

The standard pattern: compute the geohash of your search center at a precision matching your search radius (e.g., precision 6 ≈ 1.2 km cells, good for a 1-2 km radius query), find the 8 neighboring cells, do an SQL or NoSQL query for rows whose stored geohash starts with any of those 9 prefixes, then post-filter by exact haversine distance to remove false positives in the corners. Redis simplifies this with `GEOSEARCH ... BYRADIUS` (which uses geohash internally). PostGIS gives you `ST_DWithin` on `geography` columns, which is more accurate but slower. For 1 million points and 1 km queries, the geohash-prefix approach is usually 10-100× faster than a bounding box + spatial index for read-heavy workloads. Just don't forget the 8-neighbor expansion — without it you miss 30-50% of nearby results near cell edges.

The alphabet is 0123456789bcdefghjkmnpqrstuvwxyz — 32 characters chosen to avoid visually ambiguous pairs in typed or handwritten codes. Excluded letters: a (confusable with o in some fonts), i (confusable with 1, l, |), l (lowercase L looks like 1 and I), o (looks like 0). This makes geohashes phone-dictation-safe and OCR-friendly. Why base-32 rather than base-16 or base-64? Five bits per character is a sweet spot: each character refines precision by 32×, alternating 2-3 bits between lat and lng, which gives roughly square cells at most precisions and human-readable strings of 6-12 characters for typical use cases. Base-64 would compress more but introduces case-sensitivity and URL-encoding complications. The Geohash-36 variant (different alphabet) exists but never displaced the original Niemeyer encoding.

Three real weaknesses. First, non-uniform cell shape: longitude cells shrink near the poles (a level-7 cell is 153×153 m at the equator but only 76×153 m at 60° latitude), breaking the assumption that prefix length = constant ground distance. Second, the edge effect: adjacent cells can share zero characters, so prefix-based proximity needs 8-neighbor expansion. Third, antimeridian and pole singularities: encoding fails or produces odd jumps near ±180° longitude and ±90° latitude. Avoid geohash for polar science, transpolar flight planning, or applications needing constant neighbor distance — use H3 (uniform hexagons, 6 equidistant neighbors at every resolution) or S2 (equal-area squares on the sphere) instead. For global e-commerce, ride-share, and mobile analytics, geohash is still excellent because most population lives between 60° S and 60° N where its quirks are minor.
Geohash Encoder Decoder - Grid Cell System — Free Geohash tool: encode/decode geohash codes, view grid cells with real cell size, find 8 neighbors, copy 9-cell CSV f
Geohash Encoder Decoder - Grid Cell System
See also
Geography & Mapping ToolsGEOGRAPHY & MAPPING TOOLS21
WuToolsWUTOOLS