Geohash: The Trick Behind Fast Nearby Searches

A visual representation of Geohash. (Image source: Found somewhere on internet)

Ever wondered how apps like Uber, Lyft, Grab or Zomato manage to find nearby drivers, restaurants or delivery partners in a matter of milliseconds?

Behind the scenes, they rely on something called a Proximity Service. That’s a topic for another day, but today we’ll focus on one of its most important building blocks: Geospatial Indexing.

Sounds fancy, but it’s really just three words wearing a trench coat, Geo → Earth or location, Spatial → Position in space and Indexing → Organising data for faster searches.

Put them together and Geospatial Indexing is simply the art of organising location data so we can find nearby entities quickly, without asking our database to scan millions of records and reconsider its career choices. I know, we came here for Geohash, not a lesson on Geospatial Indexing, but understanding the problem makes the solution more interesting!

What are we trying to solve?

Let’s say we’re asked to build a Nearby Search feature.

The most straightforward approach would be to store everyone’s latitude and longitude and query for nearby entities based on the user’s current location. And the query might look something like this:

SELECT *
FROM entities
WHERE latitude BETWEEN current_latitude - radius
                   AND current_latitude + radius
      AND 
      longitude BETWEEN current_longitude - radius
                    AND current_longitude + radius;

Looks innocent enough, doesn’t it?

The catch is that location data lives in a 2D world. As the number of users and entities grows, efficiently answering proximity queries becomes increasingly expensive, even with indexes on latitude and longitude. And that’s where Geohash comes into the picture. It helps transform a 2D location problem into something much easier to index, partition, and search efficiently.

Now, Geohash isn’t the only player in this space. There are other approaches which we’ll briefly touch upon later.

For now, let’s understand how Geohash works and why it became such a popular choice for location-based systems.

What is Geohash?

At its core, Geohash is a hierarchical encoding system that converts latitude and longitude coordinates into a compact alphanumeric string.

For example, instead of representing a location as:

Latitude: 12.9716

Longitude: 77.5946

Geohash allows us to represent it as something like: tdr1v….

Much shorter, but that’s not the interesting part.

The real magic lies in the fact that nearby locations tend to share a common prefix. This property makes Geohash particularly useful for spatial indexing, as locations that are geographically close often end up grouped together.

While these may look like random strings to us, Geohash encodes them such that nearby locations often share common prefixes.

This allows databases and search systems to work with location data much more efficiently than repeatedly performing calculations on raw latitude and longitude coordinates.

Of course, there’s a lot more happening behind the scenes, including binary encoding, bit interleaving, and Base32 conversion. But before we get into that, let’s first understand how Geohash actually generates these strings.

How does Geohash work?

This is where things start getting interesting, so stick with me for a minute. Imagine we place the entire world map on a giant chart paper.

Before we go any further, here’s the trick I use to remember latitude and longitude because I somehow mix them up every now and then:

Latitude → Flat-itude → Horizontal → ±90

Longitude → Long-itude → 180 > 90 → Vertical → ±180

Not scientific. Not official. But it helps.

Think of the Equator and Prime Meridian as the Earth’s reference lines. The Equator splits the planet into Northern and Southern hemispheres, while the Prime Meridian splits it into Eastern and Western hemispheres. Instead of working directly with coordinates, Geohash repeatedly divides these ranges into smaller and smaller regions. At every step, Geohash determines whether the location falls in the lower or upper half.

If that sounds familiar, it’s because Geohash is essentially performing a geographic version of binary search. Instead of searching through numbers, we’re narrowing down a location on the map.

Once the location has been narrowed down sufficiently, Geohash encodes that information into the alphanumeric string representation we saw earlier.

Step-by-Step: Encoding a location into a Geohash

Enough theory. Let’s see Geohash in action.

Let’s use the following coordinates as an example:

Latitude = 12.9716

Longitude = 77.5946

Step 1: Start with the global ranges

Geohash begins with the full coordinate ranges:

Latitude : -90 to +90

Longitude : -180 to +180

It then repeatedly divides these ranges in half.

For each split:

• Lower half → 0
• Upper half → 1

If you’ve ever implemented Binary Search, this should feel familiar.

Step 2: Generate binary bits

Let’s take the longitude (77.5946) and narrow it down:

[-180, 180] → 77.5946 > 0 → 1

[0, 180] → 77.5946 < 90 → 0

[0, 90] → 77.5946 > 45 → 1

[45, 90] → 77.5946 > 67.5 → 1

[67.5, 90] → 77.5946 < 78.75 → 0

First 5 longitude bits:

10110

Doing the same for latitude (12.9716) gives:

10110

(We’ll skip the intermediate steps to save a few trees.)

Step 3: Interleave the bits

Geohash doesn’t store latitude and longitude separately.

Instead, it interleaves them:

Longitude : 1 0 1 1 0

Latitude : 1 0 1 1 0

Interleaved : 1 1 0 0 1 0 1 1 0 0

Notice how the bits alternate between longitude and latitude. Geohash always starts with a longitude bit, followed by a latitude bit, and repeats this pattern throughout the encoding process.

Step 4: Convert to Base32

Finally, the binary string is grouped into chunks of 5 bits and converted using Geohash’s Base32 alphabet:

0123456789bcdefghjkmnpqrstuvwxyz

The resulting Base32 string becomes the final Geohash.

And that’s it.

Under the hood, Geohash is essentially a sequence of binary-search decisions compressed into a compact alphanumeric string.

How is this useful?

Remember how nearby locations tend to share a common prefix?

That means we can search for nearby entities by matching Geohash prefixes instead of scanning the entire dataset.

As the Geohash becomes shorter, it represents a larger geographic area, which allows us to control the search area simply by adjusting the Geohash precision.

A proximity query might then look something like:

SELECT *
FROM geohash_index
WHERE geohash LIKE '9ur5%';

Since the Geohash column can be indexed, this effectively becomes a prefix lookup rather than a full spatial scan.

Actually, systems usually don’t stop here. They first use the Geohash prefix to narrow down the candidate set and then perform an exact distance calculation to filter out false positives and return only the entities that actually fall within the desired radius.

Limitations of Geohash

• Boundary Problem: Two nearby locations can fall into different Geohash cells and therefore different search buckets, causing nearby results to be missed if we rely solely on prefix matching.
• Cell Distortion: Geohash cells are not uniform across the globe. Their physical size varies with latitude, becoming increasingly distorted as we move away from the Equator.

Despite these limitations, Geohash remains a popular choice because it is simple, efficient, and easy to integrate with traditional databases.

Any Alternatives?

While Geohash is a fast, lightweight, and scalable approach to spatial indexing, it’s certainly not the only option.

• QuadTree: A QuadTree is a hierarchical data structure where each region is recursively divided into four smaller regions. It can provide efficient spatial lookups and is particularly useful when data is unevenly distributed across an area.
• Google S2: Google S2 takes a different approach by projecting the Earth’s surface onto a cube and recursively dividing it into smaller cells. Compared to Geohash, it handles the Earth’s spherical geometry more accurately and avoids some of the boundary issues that Geohash is known for.

Like most engineering decisions, there is no one-size-fits-all solution. Each approach comes with its own trade-offs, and the right choice ultimately depends on the scale, accuracy, and complexity requirements of the system.

But that’s the fun part, isn’t it? Different problems, different tools and always something new to figure out along the way.

Thanks a lot for reading. Hope you found something useful here!