google/open-location-code: Plus Codes as Digital Addresses Without Street Names

The addressing gap Plus Codes fill

Street addresses assume streets have names and buildings have numbers. Large parts of the world do not work that way, and deliveries, service calls and emergency responses suffer for it. Latitude and longitude solve the coverage problem but fail the usability test: 14.2 decimal digits are hard to say aloud, hard to write down, and easy to garble. Open Location Code is a library that converts a coordinate pair into a short string called a Plus Code, and converts that string back to coordinates. The README frames the goal directly: the technology is designed to produce codes that can be used as a replacement for street addresses, especially in places where buildings are not numbered or streets are not named. The audience is developers building address entry, delivery, or field data collection for those regions, not end users who will ever see the word "OLC".

How the grid encoding actually works

A Plus Code is a sequence of characters drawn from a set of 20, and the digits alternate between latitude and longitude. The first four characters describe a one degree by one degree area aligned on whole degrees. Every two further characters shrink the area to one four-hundredth of the previous one, because each pair divides both axes by 20. A plus sign sits after the eighth character, which splits the code visually and keeps it distinguishable from a postal code. The README's worked example is the Parliament Buildings in Nairobi, Kenya at 6GCRPR6C+24: 6GCR covers the area from 2°S 36°E to 1°S 37°E, and PR6C+24 identifies a 14 by 14 metre area inside it. Past ten characters the scheme stops halving and switches to a 4x5 grid, where one extra character narrows the area to roughly 3.5 by 2.8 metres. That design choice is deliberate. Doubling the digits again would overshoot the useful precision for a building entrance and force users to read two more characters for no practical gain.

The important property for implementers is that a full code decodes completely offline. There are no data tables and no network calls, which means the encoder and decoder can run on a device with no connectivity, and the same code resolves to the same area for everyone. Codes that are similar sit closer together than codes that are different, so a code is also a rough spatial index.

Shortening, recovery, and the reference location trap

Full codes are long. To make them easier to communicate, the specification allows shortening a code relative to a reference location, dropping four or more leading characters and keeping the plus sign and the tail. An 8F+GG style code is missing six leading characters; a 6C8F+GG style code is missing four. Recovery takes the short code plus a reference coordinate and reconstructs the full code. The reference used for recovery does not have to be the same location used for shortening, but it has to be nearby, and this is where the design gets fragile. The README states that when the reference comes from a town or city name, the result depends on the accuracy of the geocoding service. One service may place Zurich near the Google office, another may shift it by a hundred metres or more, and that shift can be enough to prevent the original code from being recovered. The guidance in the repository is to prefer smaller neighbourhood features over large city-sized ones, because their geocode results vary less. If your product lets users type a city name to anchor a short code, you have imported a geocoding dependency into a system whose selling point is that it needs none.

Installing the JavaScript library and encoding a first code

The repository ships sample implementations and tests per language under directories such as js/, python/, java/, go/, rust/ and cpp/. The top-level package.json names the package open-location-code and describes it as a library to convert between lat/lng and OLC codes. The README does not give a command-line install line, so the package name is the reliable starting point for a JavaScript project.

npm install open-location-code

Once installed, the implementation exposes the functions the README lists: validating a code, encoding to a standard 14 by 14 metre accuracy, encoding to any length, decoding to low, high and center coordinates, shortening relative to a location, and extending a short code relative to a location. The exact function names differ per language, so check the source file in the js/ directory rather than assuming a naming convention.

The demonstration site linked from the README is http://plus.codes/, which is the quickest way to see a code for a coordinate before writing any code. For a first real use, encode a known coordinate, then decode the result and confirm the center falls inside the low and high bounds you received. That round trip is the only behaviour you need to trust before wiring Plus Codes into an address field.

Where the library stops being the right tool

Open Location Code is not a geocoder and does not try to be one. The README says so explicitly: geocoding services are not a part of the technology. If a user types "Nairobi" and expects a Plus Code, the library will not help; you need a separate service to turn that name into coordinates, and the accuracy of that service then becomes your accuracy. A second limitation is that a Plus Code is not memorable in the way a street address is. 6GCRPR6C+24 is precise and unambiguous, but nobody describes their home that way in conversation, and voice entry of mixed digits and letters is error-prone. Third, the codes are areas rather than points, so any system expecting a single exact coordinate must decide which part of the returned low and high bounds to store. The README is silent on rollback or migration between code lengths, so if you have already stored ten-character codes, moving to a different precision is your own data problem to solve.

How it differs from Geohash and what3words

Geohash solves a similar problem with a different alphabet and a different structure. It uses base32 characters and produces a single string with no separator, so a truncated Geohash is a valid Geohash for a larger area, which makes accidental precision loss invisible. Open Location Code inserts the plus sign after eight characters precisely so a code cannot be mistaken for a postal code and so truncation is visible. The other common comparison is what3words, which maps the world to three-word addresses. That approach is far easier to say aloud, but the word list is a proprietary dataset, and recovery depends on the vendor's service. Open Location Code's algorithms are publicly available and can be used without restriction, and a full code decodes offline with no lookup table. The trade-off is real in both directions: what3words wins on human factors, Open Location Code wins on independence and offline operation. The repository includes a comparison document at Documentation/Reference/comparison.adoc for readers who want the longer version.

Licence, maintenance, and upgrade cost

The project is licensed under Apache-2.0, which permits commercial use and modification provided you keep the licence and attribution notices; this is a description of the licence text, not legal advice, so have counsel review it if your distribution model is unusual. The package.json also declares Apache-2.0 for the JavaScript package. On maintenance, the last push to the default branch was on 2026-03-30, and the repository is not archived. The published releases tell a different story from the commit activity: 1.0.4, described as an algorithm update, is dated 2019-07-29, while 1.0.3 was an encoding bug fix in 2017 and 1.0.2 a recovery code bug fix in 2017. The encoding scheme itself is stable and specified in Documentation/Specification/olc_definition.adoc, so the practical upgrade cost is low; the risk is not churn but stagnation in a specific language binding you depend on. Check the commit history of the directory for your language rather than the repository as a whole.

Editorial conclusion

Adopt google/open-location-code if your product already handles coordinates and you need a compact, offline-decodable string that behaves like an address in regions with no street naming. Do not adopt it if your users need to type or hear a place name, or if you expect the library to geocode a city name for you; the README states plainly that geocoding services are not part of the technology. Before committing, verify two things in the language implementation you plan to ship: that it exposes the shorten and recover pair you need, and that your chosen reference location resolves to the same neighbourhood on every geocoder you use, because the README warns that a hundred-metre difference in a city-level geocode can prevent the original code being recovered.

Frequently asked questions

Official sources

1. google/open-location-code on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases