Open Location Code: how the plus code grid replaces a street address
Open Location Code is a library to generate short codes, called "plus codes", that can be used as digital addresses where street addresses don't exist.
At a glance
- What is it?
- google/open-location-code turns coordinates into a short digit string you can read aloud and decode offline, with implementations in twelve directories, with no geocoding service involved.
- Who is it for?
- Adopt Open Location Code when addresses must be spoken, stored or handed over with no lookup service available, and skip it when you need a named place, a street, or geocoding. Check first that your consumers can accept an area rather than a point, then confirm the reference location used for shortening is precise enough to recover the original code.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Activity is slowing. The repository last received commits 7 months ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 14, 2026, and from our analysis. They are not legal advice.
Star history
- google/open-location-code4,372 ★ · +14
| Repository | 2026-09-23 | 2026-11-14 |
|---|---|---|
| google/open-location-code | 4.4k | 4.4k |
14 Stars in the last 52 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
Encoding an area instead of a point, with digits that alternate latitude and longitude
A plus code describes a patch of ground, not a single spot. The alphabet has twenty characters and the digits alternate between latitude and longitude, so the first four digits name a one degree by one degree cell aligned on whole degrees. Each later pair of digits cuts that cell to a twentieth of a degree in each axis, and therefore to one four hundredth of the area. Codes that resemble each other sit close together on the map, which is what makes a code usable as a human-scale reference.
The Parliament Buildings in Nairobi sit at 6GCRPR6C+24. Read it in two halves: 6GCR is the region from 2 degrees south 36 degrees east to 1 degree south 37 degrees east, and PR6C+24 picks out a 14 by 14 meter square inside it. The plus sign is placed after the eighth digit for two reasons, to make the string readable in two groups and to keep it apart from postal codes.
One detail is worth pausing on. After the tenth digit the scheme does not simply add two more digits, because each added pair would overshoot by a factor of twenty. Instead the cell is cut into a four by five grid and a single digit selects one square, landing at roughly 3.5 by 2.8 meters.
Decoding without any lookup table or network call
Full codes reverse into a location entirely offline. The project states that no data tables and no online services are involved, which is the whole point of the design and the reason it survives in places where connectivity does not.
Each language port exposes the same seven operations: checking whether a string is a valid sequence, checking whether it is a valid full code (a valid sequence is not automatically a valid full code), encoding a coordinate pair at the standard 14 by 14 meter accuracy, encoding to any requested length, decoding a code into its low, high and centre coordinates, shortening a full code against a reference location, and extending a short code back against one. Decoding returns three values rather than one, so a caller can tell a shopper which corner of the block to aim for.
Because the grid is arithmetic and the cell boundaries are fixed, a decoder needs nothing but the string. Geocoding is outside the technology by design: the documentation separates the algorithm from any service that turns a place name into coordinates.
Shortening drops leading digits, and the reference location decides how many
Shortening replaces the leading digits of a code with a nearby reference point, so that what has to be remembered is the tail. When a shortening is possible at all, it removes four or more digits from the front. How far it goes depends entirely on how close the reference location is to the target.
The recovery side is symmetrical. A short code plus a reference location returns the original area, and the reference does not have to be the same point used when shortening, only a nearby one. The plus character is always present in a short code, so the number of missing characters is trivial to compute: 8F+GG is missing six, 6C8F+GG is missing four.
This is where the design leaks. If the reference comes from a town name resolved by a geocoding service, recovery inherits that service's error. The documentation notes that one service can place Zurich near the Google office while another shifts it a hundred meters or more, which is enough to break recovery. The guidance is to anchor on a small neighbourhood feature rather than a whole city, since a district centroid is far less sensitive to geocoder differences.
Fourteen ports of the same algorithm, none of them published as an install command
The repository root holds one directory per implementation: c, cpp, dart, garmin, go, java, js, plpgsql, python, ruby, rust and visualbasic, plus android_demo, tile_server, Documentation, test_data and the Bazel build files (.bazelrc, .bazeliskrc, MODULE.bazel, WORKSPACE). Java is the primary language. Each port is a self-contained library of the seven functions above.
The README gives no package manager command, no version constraint and no build invocation for any of them. It points instead at the repository itself, at the demonstration site at plus.codes, and at a CDN listing for the JavaScript build. If you are starting from this repository, read the directory for your language and build it with the tooling that port expects; the project does not document a single path that covers all of them.
There is a small inconsistency in the tree worth noting. package.json at the root carries the name open-location-code, version 1.0.0 and the homepage http://openlocationcode.com/, a domain that is not the homepage given in the README, which is https://plus.codes. Anyone wiring up npm metadata should decide which URL to trust before publishing.
Where a plus code is the wrong answer
The failure mode is precision, and it is structural. A code with fewer digits names a bigger patch, so a four digit regional code cannot tell anyone which door to knock at. There is no way around this by formatting: the length is the accuracy.
The second failure is reference drift. Short codes only survive when the reference location is available again at recovery time, and a geocoder is not a stable reference. A code shortened against a place name that two providers resolve differently can decode to the wrong block, and nothing in the algorithm will signal the error to you.
The third is that a plus code names geography, not a destination. It carries no street, no building, no occupant, and no postal routing. Teams that need a postal service, a routing engine or an address validator are looking at the wrong library, and the README does not offer bridges to any of them.
Geohash, What3words and the difference in approach
Geohash is the closest alternative and takes a different route. It also encodes coordinates into a short string, but it uses a base 32 alphabet without the plus separator, and its refinements are uniform powers of two, so a given character length means the same cell size everywhere with no special case at the tenth digit.
What3words moves away from coordinates entirely. It divides the globe into three metre squares and names each one with a fixed word list, which makes a code readable aloud over a phone but ties the whole system to a proprietary domain and a word allocation process.
Open Location Code sits between the two. It keeps the arithmetic, offline reversibility and permissive licence of geohash, and borrows the human friendliness of a word based system without needing a word list. If you need the string to survive being read out loud in a noisy street and to be decodable with no service, that middle position is the argument for it. If you need to look a place up by name, none of the three helps, because none of them includes a geocoder.
Apache-2.0 terms, and a release history that stopped in 2019
The library is published under Apache-2.0 and the documentation states that the algorithms may be used without restriction. Embedding it in a closed product carries the usual obligations of that licence: preserve the licence text and the notices, and state any modifications. That is a reading of the licence terms, not legal advice.
The repository is not archived and the last push landed on 2026-03-30, so changes are still landing, but the published releases tell a different story. The newest tags are 1.0.4 from 2019-07-29, 1.0.3 from 2017-11-15 and 1.0.2 from 2017-08-25. The root package.json still says version 1.0.0. A reader should assume a stable, finished specification and pin to a specific commit rather than tracking a tag stream.
Editorial conclusion
Adopt Open Location Code when addresses must be spoken, stored or handed over with no lookup service available, and skip it when you need a named place, a street, or geocoding. Check first that your consumers can accept an area rather than a point, then confirm the reference location used for shortening is precise enough to recover the original code.
Frequently asked questions
What is Open Location Code?
It is a Google library that encodes a latitude and longitude pair into a short digit string called a Plus Code, built from an alphabet of 20 characters that alternate between latitude and longitude. The code describes an area rather than a point, and a full code converts back to a location completely offline.
How precise is a plus code?
The standard encoding produces a 14 by 14 meter area, which is the accuracy used by the encode function in every language port. A single grid refinement after the tenth digit reaches roughly 3.5 by 2.8 meters.
How do I recover a shortened plus code?
Pass the short code and a nearby reference location, which does not have to be the exact point used to shorten it. If the reference is a town name resolved by a geocoder, the result depends on that service's accuracy, so the guidance is to anchor on a smaller neighbourhood feature.
Does Open Location Code include geocoding?
No. The documentation places geocoding services outside the technology and states that only the encoding, decoding, shortening and recovery algorithms are covered. If a reference location is given as a place name, resolving that name needs a separate service.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/google-open-location-code)Star history chart for your README
[](https://hysenlabs.com/projects/google-open-location-code)Was this useful?