Coordable (Articles sur pricing)

How we cut geocoding costs by 79% across Europe

Julien Crétin — Mon, 15 Jun 2026 09:00:00 GMT

A benchmark of OSM, HERE, and Google across 12 countries and 6,000 residential addresses.

Geocoding 500,000 European residential addresses per month with Google Maps as the sole provider costs $30,000 per year. We ran a benchmark across 12 European countries and 6,000 addresses using a cascade strategy that calls free OSM first, then HERE, then Google. In our test the cascade resolved 86.3% of addresses correctly (within 100m of the national reference coordinate), against 73.7% for Google alone, at a cost of about $6,300 per year at the same volume. That is a 79% cost reduction with a 12.6 percentage point quality gain.

That average hides large per-country variation. At the same 500,000 addresses per month, the cascade saves between $15,000 and $30,000 per year per country against Google alone, with quality gains ranging from +3 to +34 percentage points depending on the country. We give the full per-country breakdown below so you can read off your own situation.

The cascade dominates Google on both axes in every single country we tested. There is no country where defaulting to Google is the better choice. But the optimal cascade configuration varies dramatically across Europe: in the Netherlands, free OSM data alone resolves nearly every address, while in Finland and Italy even the full three-provider cascade leaves a quarter of addresses unresolved. The orchestration logic matters more than the choice of providers.

This article walks through the dataset, the protocol, what we found, and what it means for any team running geocoding at scale in Europe.

The headline, at 500,000 EU residential addresses a month: better coverage, 79% cheaper.

Table of contents:

Why this matters

Most engineering teams default to Google Maps for geocoding. The reasoning is reasonable on paper: Google has the largest map data footprint in the world, the API is well documented, and "nobody got fired for buying Google". Then the bill arrives.

At $5 per thousand requests, Google geocoding is the most expensive of the three major options by a factor of six against HERE and by an infinite factor against OSM. Teams notice this when their geocoding spend hits the financial dashboards, usually around the time logistics, e-commerce, or fleet operations scale into hundreds of thousands of monthly addresses.

Number of addresses:

Costs use each provider's per-1,000 rate; free tiers are not deducted (marginal at this scale, e.g. 10,000 free requests for Google, 30,000 for HERE).

Most teams just absorb the cost, or swap Google for a single cheaper provider and brace for a quality drop. The better response is to question the default. Geocoding is not a problem where one provider is uniformly superior. It is a problem where data sources, coverage, and pricing vary by country, and where a smart routing layer outperforms any single provider on both cost and quality.

We wanted to put numbers on that claim. So we built a benchmark.

The dataset

We constructed a 6,000-address sample stratified across 12 European countries: France, Spain, Italy, the Netherlands, Denmark, Norway, Portugal, Finland, the Czech Republic, Lithuania, Slovakia, and Slovenia. 500 addresses per country, all residential.

The 12 benchmarked countries, 500 residential addresses each. The UK is hatched: no open national address dataset.

The address sources are national authoritative registries, aggregated through OpenAddresses for 11 countries and through CartoCiudad (the Spanish national mapping agency) for Spain. We deliberately chose residential rather than business addresses, because residential is where geocoding actually breaks: business addresses tend to cluster on well-named commercial streets, while residential includes the long tail of suburban subdivisions, rural hamlets, and post-2010 developments that geocoders struggle with.

The United Kingdom is missing from the benchmark, and that absence is itself worth noting: Ordnance Survey AddressBase, the only complete UK address registry, remains paywalled. There is no open national address dataset for the UK comparable to France's BAN or Spain's CartoCiudad. This is a structural blind spot in European open data that affects every open-source geocoding effort.

Each address in the sample carries a reference coordinate from the national registry: a postal code, a city, a street name, a house number, and a (lat, lng) pair. We treat the (lat, lng) as a reference coordinate, not as ground truth. Ground truth would require a field GPS reading, which we do not have. National registries have their own errors: parcel centroids that differ from the actual building entrance, projection drift, missing recent constructions. The cleanest way to phrase what we measure is "divergence from the national reference", not "provider error". That distinction matters for the methodology and we return to it.

The protocol

A note on terms first. Google and HERE are commercial providers that bundle their own data, engine, and hosting. OpenStreetMap is an open referential that we query through a separate engine, and the engine choice matters, which is why we use Photon rather than Nominatim (more below). We geocoded the 6,000 addresses three times independently, once with each of the three: OpenStreetMap, HERE, and Google. We kept the raw output for every provider on every address, with no quality filtering at geocoding time. This is the critical choice. By geocoding all 6,000 addresses with all 3 providers, we can reconstruct the cascade afterward with whatever logic we want, and measure the marginal contribution of each step.

About the OSM provider choice: we initially ran Nominatim and got 6.4% completeness on the Czech sample. This was not a fair measurement of OSM coverage. The public Nominatim instance enforces a 1 request per second rate limit and treats timeouts as no-result, which crushes the apparent hit rate. The same addresses fed to Photon, which uses the same OSM data behind an Elasticsearch index, returned 74.4%. We switched to Photon for all subsequent runs. The Photon numbers reflect what OSM data can actually do; the Nominatim numbers reflected operational throttling, not data coverage.

For each provider, we then needed a decision rule: "did this provider produce a usable result?" In production, a cascade has to decide whether to accept a result and stop, or fall through to the next provider. It has to do this without access to a reference coordinate, since if you had a reference coordinate you would not need to geocode.

We started with a simple rule: trust the provider's own classification. HERE returns a confidence score that can be thresholded at 0.8. Google and Photon do not return useful confidence scores, so we used their classification labels (HOUSENUMBER versus LOCALITY versus UNRESOLVED).

This failed in interesting ways. For Slovakia, Google was returning 1.2% HOUSENUMBER, which is implausible. The actual Google results for Slovak addresses were correct: the right street, the right number, coordinates within meters of the reference. But the off-the-shelf classification we started with was misreading the Slovak address format ("village name + number" without a separate street) and labeling correct rooftop results as LOCALITY or POI. A label-based decision rule was throwing away correct answers because the labels were wrong.

We replaced the label-based rule with a textual one: a result is accepted if the formatted_address returned by the provider contains the street name, the house number, and either the city or the postal code from the input. This is what a human reviewer would do to validate a match. It is provider-agnostic, language-agnostic to a useful degree, and it makes no use of the reference coordinate, so it is something that could run in production.

This rule is not perfect, and we want to be transparent about that. We applied it manually for this benchmark as a way to evaluate cascade behavior more honestly than the provider labels allowed. At production scale, validating thousands of geocoded results requires more sophisticated approaches: cross-provider consistency checks, semantic matching with language models, learned rejection thresholds. We are working on a follow-up article on exactly that question, comparing an LLM-based result validator against the manual rule we used here. The takeaway for now is that this kind of validation logic, not the provider choice, is what unlocks cascade performance.

The headline results

Here are the two strategies side by side, evaluated on the full 6,000-address sample, with cost shown as annual spend at a 500,000 addresses per month workload (Google $5/1k, HERE $0.83/1k, OpenStreetMap $0).

Strategy	Acceptance	Confirmed hits (<100m from reference)	Cost / year	Cost per 1,000 confirmed hits
Google alone	77.9%	73.7%	$30,000	$6.79
Cascade (OSM → HERE → Google)	89.9%	86.3%	$6,336	$1.22

Two things stand out.

First, the cascade beats Google alone on every metric. It accepts more addresses, it lands more of them within 100m of the reference, it has a lower rate of false positives, and it costs roughly a fifth of what Google alone would.

Second, the free tier does the bulk of the work. OpenStreetMap alone resolves about 60% of addresses at zero cost. Only the roughly 40% it cannot handle fall through to HERE, and only the roughly 13% that HERE cannot handle ever reach Google. By the time an address reaches the most expensive provider, it is one of a small minority. This is the entire economic logic of a cascade.

OpenStreetMap clears most addresses for free; only a small share ever reaches a paid provider.

Whether you should drop a provider from this cascade, and whether Google's last few points are worth their cost, is something we return to in What this means for your stack. But the headline is simple: the expensive provider should be the last resort, not the default.

The country-by-country picture

The headline numbers hide the most important finding: country-by-country variance is enormous. Here are Google alone and the full cascade broken down per country, with the cascade's gain over Google, sorted from the easiest country to the hardest.

Country	Google alone	Cascade	Gain
Netherlands	90.4%	100.0%	+9.6
Slovenia	94.6%	98.4%	+3.8
Spain	89.8%	95.0%	+5.2
Lithuania	60.2%	94.4%	+34.2
France	85.0%	91.2%	+6.2
Czech Republic	84.6%	88.0%	+3.4
Slovakia	73.0%	87.0%	+14.0
Portugal	69.8%	85.4%	+15.6
Denmark	69.6%	82.0%	+12.4
Norway	67.2%	80.0%	+12.8
Italy	65.0%	74.0%	+9.0
Finland	34.6%	60.2%	+25.6

Google alone versus the full cascade, country by country. The gain runs from +3.4 to +34.2 points.

The variance is the story.

Netherlands is the easy case: OSM alone resolves nearly every Dutch residential address correctly, because the Dutch community has done extraordinary work mapping their country into OSM, much of it imported directly from the BAG (Basisregistratie Adressen en Gebouwen), the national registry of addresses and buildings, which the government publishes under an open licence. The full cascade reaches 100% completeness at zero geocoding cost. If your business operates only in the Netherlands, you do not need a commercial geocoding provider at all. In practice a Dutch team might not reach for OSM here at all: the government runs its own free geocoder, PDOK Locatieserver, on the same BAG data, and open-source tooling such as NLExtract turns that official open data into a geocoder you can run yourself. The flip side of this shared lineage is a measurement caveat we cover in Honest limitations.

Lithuania is the surprise: Google alone resolves only 60.2% of Lithuanian residential addresses correctly, but Photon brings that to 94.4%. We expected the Nordic and Baltic countries to be a weak spot for OSM, and instead Lithuania is one of the strongest performers. The +34.2 point gain over Google alone is the largest in the dataset.

Spain, France, Czech Republic, Slovenia are the steady middle: Google alone gets you to the mid-to-high 80s, the cascade adds a few points at low marginal cost, and the value of HERE is small in these countries. A two-provider cascade is sufficient.

Denmark, Norway, Slovakia, Portugal are the structural gain zone: the cascade adds 12 to 16 points over Google alone. HERE and Google together cover what neither could alone. The cascade costs more here, but the quality lift is large.

Italy and Finland are the hard countries: even the full cascade leaves a quarter to forty percent of addresses unresolved within 100m. There is no clever orchestration that fixes this with the providers we tested. Italy has notoriously inconsistent residential addressing (the same Via Roma appears in thousands of municipalities, civic numbers come with suffixes, parenthetical disambiguators, and saint names that geocoders confuse). Finland is harder still because the OpenAddresses source for Finland does not include a city field, only street + postcode + country. That kind of partial input is closer to what a real-world delivery dataset looks like, and it punishes every provider equally.

What this means: there is no single optimal cascade for Europe. The Netherlands cascade is "Photon only, stop". The Lithuanian cascade is "Photon, then occasionally HERE". The Finnish cascade is "all three, and accept that 40% will need manual review". A geocoding strategy that does not adjust by country is leaving money or quality on the table.

Annual savings at scale

The headline showed the blended average. The country-level numbers are where the real money is, and where the variance becomes impossible to ignore. We use the same 500,000 addresses per month workload, broken down country by country, so you can read off your own situation: if you operate at this volume in France, your numbers are the France row; if you run 200k per month across two countries, take 40% of the relevant rows and add them.

One number is identical everywhere: geocoding 6 million addresses a year with Google alone costs $30,000, since Google charges $5 per thousand requests in every country. What varies, dramatically, is what the cascade costs. And that variance is the whole point of this article.

Country	Quality gain	Cascade cost / year	Savings / year	Reduction
Netherlands	+9.6	$20	$29,980	100%
Slovenia	+3.8	$1,694	$28,306	94%
Lithuania	+34.2	$2,058	$27,942	93%
Spain	+5.2	$2,952	$27,048	90%
Slovakia	+14.0	$2,957	$27,043	90%
France	+6.2	$5,328	$24,672	82%
Czech Republic	+3.4	$5,961	$24,039	80%
Denmark	+12.4	$7,794	$22,206	74%
Norway	+12.8	$8,244	$21,756	73%
Italy	+9.0	$11,732	$18,268	61%
Portugal	+15.6	$12,543	$17,457	58%
Finland	+25.6	$14,744	$15,256	51%
AVERAGE	+12.6	$6,336	$23,664	79%

What you pay versus what you save, per country, against Google's flat $30,000 a year.

A few observations on this table.

First, the cascade beats Google alone in every single country. The smallest annual saving is $15,256 in Finland, the largest is $29,980 in the Netherlands. There is no scenario in our benchmark where defaulting to Google is the right call at this volume.

Second, the variance in savings tracks the variance in cascade cost, not Google cost. Google is $30,000 everywhere. The cascade costs $20 in the Netherlands (essentially free, Photon resolves nearly everything) and $14,744 in Finland (Photon struggles with Finnish addressing, the cascade falls through to the paid providers far more often). So the question "how much does the cascade save me in country X" boils down to "how good is OSM coverage in country X". That is the same country variation we saw in the quality breakdown above.

Third, the percentage reductions are remarkably high even in countries where the cascade adds little quality. Czech Republic gains only +3.4 quality points, but still saves 80% on cost because Photon resolves 87% of Czech addresses for free. The cascade does not need a quality breakthrough to be massively cheaper. Even where it ties Google on quality, it beats Google on cost.

Fourth, the Netherlands is the limit case worth its own mention. Free OSM data resolves nearly every address that the cascade is called on, leaving essentially zero paid calls. Annual cost: $20. If your geocoding workload is mostly Dutch, you do not need a paid geocoding provider at all. We would not have predicted this five years ago, but the Dutch OSM community has done that good a job.

To extrapolate to your own volume, the numbers scale linearly. At 1 million addresses per month per country, the savings double; below that, they shrink in proportion. The percentage reductions are constant, the absolute numbers scale with traffic.

Honest limitations

A few caveats matter and we want to name them.

HERE and OpenAddresses share data sources in some countries. HERE is upfront in their documentation that "HERE Map Content" incorporates public national datasets where available. In France, this includes the BAN, which is also a source for OpenAddresses. This creates a partial overlap on our reference coordinate metric: when HERE answers from BAN-derived data and we compare it to a BAN-derived reference, the match is mechanical. To quantify this, 41% of HERE results sit within 1 meter of the reference coordinate, against 31% for Photon and 10% for Google. The other 59% of HERE results diverge meaningfully from the reference, so HERE is not a copy of OpenAddresses, but the comparison metric does favor providers that source from the same national registries. We return to the cascade with HERE removed entirely in What this means for your stack, so readers who want to discount this effect can see those numbers.

The same shared-source effect applies to OSM, most visibly in the Netherlands. Dutch OSM addresses are largely a BAG import, and our Dutch reference, sourced through OpenAddresses, traces back to the BAG as well, so the near-perfect Dutch result partly reflects a common origin rather than two independent systems agreeing. This does not change the practical takeaway, free OSM data resolves Dutch addresses whatever its provenance, and the government's own PDOK service runs on the very same data, but the 100% figure should be read as completeness against the national registry, not as proof that OSM is independently more accurate than a paid provider. Where no such open registry feeds OSM, the cascade leans much harder on the paid providers, which is exactly what the per-country cost spread shows.

The robust validation rule was applied manually. As discussed in the methodology section, deciding whether a geocoded result matches the input is the hard problem. Simple confidence thresholds fail because Google and Photon do not return useful scores. Simple label thresholds fail because the upstream classification can be unreliable on certain address formats. The textual rule we used (street + number + city/postcode in formatted_address) works for a benchmark, but it required country-by-country sanity checking and tolerance for synonyms (Calle and Carrer, Via and Strada, postal code formats with or without separators). A production cascade running at scale needs a more robust validation layer. This is the topic of our next benchmark.

Address completeness varies by source. OpenAddresses data for Denmark, Norway, and Finland does not include a city field. The geocoding inputs for these countries are therefore more impoverished than for the others (just street + postcode + country). This degrades all providers symmetrically, but it does inflate the apparent difficulty of these countries. Real-world delivery data often has similar gaps, so the measurement reflects production conditions more than ideal conditions.

6,000 addresses is not the entire population. Statistical noise is real at this sample size, especially at the country level (500 addresses per country). The directional findings are robust, the second decimal place is not.

What this means for your stack

If you are running geocoding at any meaningful European volume, four things follow from this benchmark.

The two cascades sit top-left: more confirmed hits at a fraction of the cost. Cutting HERE moves you right and down.

First, stop defaulting to Google. The full cascade beats Google alone in every country we tested, on both cost and quality. There is no defensive argument for "we use Google because it is the best". On this dataset, Google alone is dominated: 73.7% confirmed at $30,000 a year, against 86.3% at $6,336 for the cascade.

Second, if you trim the stack, cut Google before HERE, never the reverse. The instinct when simplifying a cascade is to keep the famous provider and drop the unfamiliar one. On these numbers that is exactly backwards (our Google vs HERE comparison goes deeper on the two). A cascade with HERE removed entirely, OSM then Google, resolves only 81.8% of addresses and costs $12,720 a year, because every address OSM misses falls straight onto Google at $5 per thousand. The full cascade, with HERE absorbing the middle tier at $0.83 per thousand, lands more addresses (86.3%) for half that cost. HERE is the cheap workhorse, not the expendable one. If you want a genuinely lean stack, the right cut runs the other way: OSM then HERE, no Google at all, returns 83.2% confirmed at $2,116 a year. That is 96% of the full cascade's quality for a third of its cost.

Third, Google's last few points are cheap, but their value is concentrated in a handful of countries. Adding Google on top of an OSM-then-HERE cascade buys 3.1 percentage points of quality, from 83.2% to 86.3%, for an extra $4,220 a year, about 2.3 cents per additional correctly resolved address. In absolute terms that is inexpensive, so for a mixed European footprint the full cascade is the right default. But the gain is not evenly spread. In the Czech Republic, Slovenia, Spain, and Slovakia, Google adds under two points and barely earns its place in the cascade. In Portugal it adds fifteen points, in Italy almost six. If your traffic is concentrated in OSM-strong countries, OSM then HERE is enough. If it includes the hard ones, Google stays in.

Fourth, the orchestration logic matters more than the provider choice. A naive cascade that just chains OSM, HERE, and Google without a smart decision rule on when to accept a result will inherit the false positives of the cheaper providers and lose the cost-quality advantage. We showed in the protocol that switching from a label-based decision rule to a textual one moved cascade quality by several percentage points. The provider stack is the easy part. The accept and reject logic is the hard part.

One last point on simplicity, because it is easy to overcorrect. A simple uniform cascade already wins; country-aware routing is the next gain, not a prerequisite. Run the same three providers in the same blind cheap-to-expensive order in every country, and you still beat Google alone everywhere, on both cost and quality. You do not need clever per-country provider selection to capture the bulk of the value. Where country-awareness pays off is the bill: serving the Netherlands from OSM alone, calling OSM then HERE where Google earns nothing, and reaching for all three only where it does, trims cost further without touching quality. That refinement is what we are building. The simple uniform cascade is already the right move today.

What comes next

The biggest open question from this benchmark is the one we sidestepped: how do you decide, at production scale and without a reference coordinate, whether to accept a provider's result? The textual rule we applied here works for a benchmark of 6,000 addresses. At 500,000 a month and up, it needs to be automated, robust to language and formatting variants, and able to catch the failures the textual rule misses: the right street and number but the wrong city, or the correct address pinned a few hundred meters down the road.

Two directions follow from this. The first is the accept-or-reject decision itself. Provider confidence scores and labels are the obvious signal to lean on, and a real question is how far they can be trusted: on Slovak addresses, the providers' own labels flagged correct results as failures. So the more promising path may be external, can a language model flag a bad result from the input and output pair alone, with no reference coordinate, well enough to replace the manual rule? That layer is the missing piece that lets a country-aware cascade run unattended at scale. The second direction sits upstream: most real-world address data is far messier than a national registry, and how much of the geocoding gap closes with input cleaning rather than a better provider is still an open question. Both are what we are looking at next.

Methodology recap

For readers who want to reproduce or audit the analysis:

Dataset: 6,000 residential addresses, 500 per country, 12 European countries, sourced from OpenAddresses (11 countries) and CartoCiudad IGN (Spain). Schema: id, street_name, house_number, city, postal_code, country, country_code, full_address, lat_ref, lng_ref.
Geocoders: OSM via Photon (not Nominatim), HERE, Google. All addresses geocoded once with each, raw outputs preserved.
Validation rule: provider result accepted if (a) latitude returned, (b) house_number from input appears in formatted_address from provider, (c) at least one significant token of street_name from input appears in formatted_address from provider, (d) city or postal_code from input appears in formatted_address from provider. For HERE only, additionally requires confidence_score >= 0.8.
Confirmed hit: accepted result within 100m of the reference coordinate (haversine distance).
Cost basis: Google Geocoding API $5/1k, HERE Geocoding $0.83/1k, OSM via Photon $0 (self-hosted or platform-included).
Cascade logic: blind cascade in production order (cheaper first, expensive last). Each step calls the next only if the current one was not accepted.
Volume normalization: costs reported as annual spend at a workload of 500,000 addresses per month (6 million addresses a year).

The full per-address dataset (6,000 rows, 34 columns) is available on request.

Where to go from here

If you are choosing or trimming a geocoding stack, these pages go deeper on the pieces this benchmark touches:

Provider guides: Google Maps Geocoding API, HERE Geocoding API, Mapbox Geocoding API.
Head to head: Google vs HERE geocoding in 2026.
Country deep dives: France, Germany, Italy, Luxembourg, Portugal, Spain, United Kingdom.

US Census + Google Maps: How to cut geocoding costs by 90% for US addresses

François Andrieux — Sat, 21 Mar 2026 10:00:00 GMT

The setup

We wanted to test the effectiveness of a cascading geocoding strategy for US addresses. We took 1,000 real US addresses (a mix of residential and business addresses, of variable quality but overall correct) and ran three geocoding tests.

Here is the summary of the results:

Test	Provider(s)	Addresses resolved	Cost per 1,000
1	US Census only	91.9%	$0.00
2	Google Maps only	92.6%	$5.00
3	US Census → Google Maps (cascade)	97.3%	$0.41

The cascade delivers 97.3% addresses found at $0.41, compared to $5.00 for Google Maps alone. That is a 90% cost reduction with a +5.4 percentage point improvement in addresses resolved. Amazing right?

Read on to see how each test was run and what the results look like.

Table of contents:

Test 1: US Census Geocoder

What is the US Census Geocoder?

The US Census Geocoder is a public and free API provided by the US federal government. It is not open source (the underlying software and data are maintained by the Census Bureau), but it is freely accessible, requires no API key, and has no published usage limits or cost.

It is built on TIGER/Line data, the official US address dataset. Results are interpolated on the street rather than placed at the exact building location (no rooftop precision). For most use cases (delivery routing, territory analysis, customer mapping), street-level interpolation is entirely sufficient.

The output data is in the public domain, with no licensing restrictions on how you store or use the coordinates.

Important limitation: US Census only understands structured street addresses. It cannot geocode points of interest, business names, or company names. If your dataset contains entries like "Starbucks, Chicago" or "Boeing headquarters", US Census will return nothing for those rows. In that case, the 90% cost reduction figure will not hold: a commercial provider will need to handle a much larger share of your requests. This strategy works best for datasets of clean street addresses ; see below for a solution.

Results

Accuracy: 91.9% (919 out of 1,000 addresses resolved)
Cost: $0.00

Test 1, US Census only: 919/1,000 addresses resolved, at no cost.

91.9% is a strong result for a free API. The 8.1% of unresolved addresses are typically due to non-standard formatting, missing components, or addresses that simply do not appear in the TIGER/Line dataset.

Test 2: Google Maps Geocoding API

What is Google Maps Geocoding?

Google Maps is one of the most widely used geocoding providers. At $5.00 per 1,000 addresses (after the free quota), it is also one of the most expensive.

It returns different precision levels: ROOFTOP for exact building locations, and RANGE_INTERPOLATED for street-level interpolation. For a fair comparison with US Census, which only returns street-level results, we accept both ROOFTOP and RANGE_INTERPOLATED in this test.

Licensing note: Google Maps results come with significant restrictions beyond the price. Google's Terms of Service do not allow you to store geocoded coordinates long-term or use them outside of a Google Maps display context. If you need to build a database of geocoded addresses, use the results in a non-Google mapping tool, or export coordinates for analysis, you may be violating Google's terms. This is an important constraint to factor in before committing to Google as your primary geocoding provider.

Note: Google free quota is excluded from these cost figures, as its effective value depends on overall usage across all Google Maps products. The $5.00 figure reflects the standard pay-as-you-go rate.

Results

Accuracy: 92.6% (926 out of 1,000 addresses resolved)
Cost: $5.00

Test 2, Google Maps only: 926/1,000 addresses resolved at ROOFTOP or RANGE_INTERPOLATED level, at $5.00 per 1,000.

Google Maps edges out US Census by 0.7 percentage points (92.6% vs 91.9%), but at a cost of $5.00 per 1,000 addresses vs $0. For this dataset, paying for Google Maps buys very little extra accuracy on its own.

Test 3: US Census + Google Maps (cascade)

How the cascade works

The cascading strategy is straightforward:

Send every address to US Census first. If US Census returns a valid result, use it. Cost: $0.
For addresses that US Census could not resolve, send them to Google Maps. Cost: $5.00 per 1,000 for this subset only.

In our test, approximately 90% of addresses were resolved by US Census (free), and only ~8% required Google Maps, at a total cost of $0.41. The remaining ~2.7% were not resolved by either provider.

This is why the cost drops so dramatically: instead of paying $5.00 for every address, you only pay Google's rate for the small fraction that US Census could not handle.

The two-provider cascade configured in Coordable: US Census first, then Google Maps for unresolved addresses, accepting both ROOFTOP and RANGE_INTERPOLATED results.

Results

Accuracy: 97.3% (973 out of 1,000 addresses resolved)
Cost: $0.41
Provider split: ~90% resolved by US Census · ~8% resolved by Google Maps · ~2.7% unresolved

Test 3, US Census → Google Maps cascade: 973/1,000 addresses resolved, at $0.41 per 1,000.

The cascade delivers a +5.4 percentage point improvement over either provider alone, at 8% of the cost of Google Maps. The key insight is that US Census and Google Maps fail on different addresses. Addresses that US Census cannot parse or match are often resolved by Google's more robust parsing engine, and vice versa.

Set up cascading geocoding with Coordable

Going further: adding a third provider

This two-provider cascade already delivers strong results, but you can push accuracy even higher by adding a third provider.

For example, adding HERE as a second fallback (after Google Maps) would catch some of the 2.7% of addresses that neither US Census nor Google resolved. HERE has strong US address coverage and is significantly cheaper than Google Maps at $0.83 per 1,000 addresses. A three-provider cascade (US Census → Google Maps → HERE) would likely push accuracy above 97.3% while keeping the overall cost low, since HERE would only handle the tiny fraction of addresses that both previous providers missed.

We ran a similar experiment with French addresses using the BAN API (the French government geocoder), Google Maps, and HERE, and achieved 97.7% accuracy at $1.62 per 1,000, a 67% cost reduction compared to Google alone. The principle is identical: route easy addresses through the cheapest provider, and reserve expensive providers for the hard cases. See How to reduce geocoding costs by 67% for the full breakdown.

Conclusion

For US address geocoding, the US Census Geocoder is a powerful and underused tool. It is free, requires no API key, and handles the vast majority of clean street addresses correctly. Pairing it with Google Maps as a fallback gives you the best of both worlds: near-complete coverage at a fraction of the cost.

Test	Provider(s)	Found	Cost per 1,000
1	US Census only	91.9%	$0.00
2	Google Maps only	92.6%	$5.00
3	US Census → Google Maps (cascade)	97.3%	$0.41

The key caveat: this strategy works for street address datasets. If your data contains business names, POIs, or unstructured inputs, US Census will not help and you will need a commercial provider for a larger share of requests.

However, it would have been possible to plug a low-cost provider to handle the remaining addresses as well : HERE, Nominatim (OSM), OpenCage, etc.

If you want to implement this cascade without writing custom code, Coordable lets you configure multi-provider workflows with quality rules at each step, so only good results pass through.

Try cascading geocoding with Coordable

Where to go from here

See how the same cascading approach cuts costs by 67% for French addresses: How to reduce geocoding costs by 67%
Compare geocoding prices across all major providers: Geocoding prices in 2026
Learn more about Google Maps Geocoding: Google Maps Geocoding API

How to reduce geocoding costs by 67%

François Andrieux — Sun, 08 Mar 2026 10:00:00 GMT

The use case: a logistics company paying way too much for geocoding

If you work in logistics, insurance, or routing software, you know the drill: geocoding volumes are massive, and the bills that come with them are too.

In this article, we show how Coordable helped a logistics company cut geocoding costs by 67% while also increasing its share of valid geocoding results from 94% to 97.7%. Total savings: $20,280 per year. 🤩

Let's dive in.

Table of contents:

The problem: choosing between cost and quality

You have probably faced this tradeoff: premium providers like Google Maps deliver excellent results, but they come at a price. Cheaper alternatives may leave some addresses unresolved.

Most of the time, though, you do not actually need the premium option; addresses are clean and unambiguous, so any decent geocoder will do the job. The real challenge appears when your address data is messy: in those cases, you are forced to choose between paying for Google Maps to guarantee correct results, or accepting that a cheaper provider will miss some.

The solution: cascading providers

Good news: there is a strategy that gives you the best of both worlds, cascading geocoders. The principle is straightforward:

Use an open-source or low-cost provider for ~90% of geocoding requests (the clean, unambiguous addresses).
Use a premium geocoder (or several) to resolve the remaining ~10%.

This approach raises geocoding success rates while keeping costs down. In our case, it reduced costs by 67% and increased the share of successfully geocoded addresses by +3.7%. Here is how we did it.

The workflow: 3 providers

Our logistics client needed to geocode mostly residential addresses in France. France has an excellent government API for this purpose, the Base Adresse Nationale (BAN), which covers French residential addresses very well, though it does not handle points of interest or addresses outside France. Many commercial providers actually use BAN data to improve their own results.

The downside of BAN's API is that it is less robust at parsing and matching poorly formatted input. So we still needed to pair it with at least one commercial provider to ensure no addresses slip through. For that, we chose Google Maps. Finally, we added HERE as a second fallback because HERE also leverages BAN data, making it a strong option for the French addresses that Google could not resolve to rooftop level.

Here is our strategy:

French BAN: confidence score > 0.75 required.
Google Maps API: ROOFTOP location type required (if not resolved in step 1).
HERE: confidence score > 0.75 required (if not resolved in step 2).

The three-provider cascade configured in Coordable: BAN → Google Maps → HERE, each step gated by a quality rule.

We apply quality rules at each step to discard results that are not good enough. For French BAN and HERE, the confidence score reflects how closely the geocoder matched the input string. Although computed slightly differently across providers, both scores are a reliable way to filter out poor results. Setting the threshold at 0.75 is fairly strict, but the cascade makes this safe; any address rejected at one step simply moves to the next provider.

Google Maps does not provide a confidence score, so instead we filter on the location type returned (ROOFTOP, APPROXIMATE, GEOMETRIC_CENTER). For residential addresses, we require ROOFTOP only, to ensure the coordinates are placed in front of the building rather than somewhere in the middle of the street.

The results

To measure the impact, we ran two geocoding sessions on the same dataset and compared them:

Google Maps only: the client's initial setup.
Cascading strategy: BAN → Google Maps → HERE.

The test dataset contains 1,000 residential addresses, mostly clean and well-formed. That is large enough to get a reliable picture of how this strategy performs at scale.

In practice, the client geocodes about 500,000 addresses per month.

Session 1: Google Maps only

Session 1, Google Maps only: 940/1,000 addresses resolved at ROOFTOP level, at $5 per 1,000.

Results:

94% valid geocoding results (addresses resolved to ROOFTOP).
Estimated cost: $5.00 per 1,000 addresses.

Note: these costs ignore the Google free quota, which is shared across all Google Maps products. Its effective value depends on each client's overall usage, so we exclude it for a fair comparison.

Session 2: BAN + Google Maps + HERE (cascading)

Session 2, Cascading strategy: 977/1,000 addresses resolved, at $1.62 per 1,000.

Results:

97.7% valid geocoding results, a +3.7% improvement.
Estimated cost: $1.62 per 1,000 addresses.

Provider breakdown: BAN 64.5% · Google Maps 31.7% · HERE 3.8%

Using BAN means that 64.5% of addresses cost nothing to geocode. Our strict rules then sent 31.7% of addresses to Google Maps, and HERE handled the remaining 3.8%.

Total cost reduction: 67%, while improving geocoding quality.

Yearly cost savings

At 500,000 addresses per month, the client was spending about $2,500/month on Google Maps alone. With the cascading strategy, that bill drops to $810/month, without any loss of quality; on the contrary.

	Monthly cost	Annual cost
Google Maps only	$2,500	$30,000
Cascading (BAN + Google + HERE)	$810	$9,720
Savings	$1,690	$20,280

That is $20,280 saved per year, while resolving +3.7% more addresses correctly.

Conclusion

If you are paying Google Maps rates for every address, you are likely overpaying. This real-world example shows how large the gap can be: by routing the bulk of clean French addresses through the free BAN API, reserving Google Maps for harder cases, and using HERE as a final safety net, the client went from 94% to 97.7% geocoding success while paying 67% less.

The key is combining the right providers in the right order, and enforcing quality rules at each step so only genuinely good results pass through. The result is a system that is both cheaper and more reliable than relying on a single provider.

Set up cascading geocoding with Coordable

Where to go from here

Learn more about the providers used in this workflow: Google Maps Geocoding API, HERE Geocoding API.
See how providers compare in France: Best geocoding providers for France.
Compare Google and HERE head-to-head: Google vs HERE for geocoding.
See current geocoding prices at a glance: Geocoding prices in 2026.

HERE price increase by 6% in 2026

François Andrieux — Fri, 06 Mar 2026 12:00:00 GMT

HERE Technologies is updating its pricing from April 2026. This post summarizes what matters for geocoding users: effective date, what changes, and who is affected.

Table of contents:

What HERE announced

From April 1, 2026, the price of the HERE Base Plan will increase by 6% for new contracts, renewals, and extensions. Existing contracts remain unchanged until renewal or extension.

HERE Technologies communicated the following:

The prices of all 35 HERE Location Services and Data IO using the pay-per-transaction model will increase by 6%.
This price increase applies to all new subscriptions and (auto-)renewals from April 1, 2026 onwards.
The price of the Developer technical support plan remains unchanged.
These pricing updates will be reflected in all future contracts and invoices from April 1, 2026 onwards.

What this means for you

If you sign a new contract or renew on or after April 1, 2026, you will see the new 6% pricing. For coverage, rate limits, licensing, and current pricing details, see our HERE Geocoding API guide.

Where to go from here

HERE Geocoding API — coverage, rate limits, and licensing.
Geocoding prices in 2026 — compare HERE with other providers.
Google vs HERE for geocoding — head-to-head comparison.

Geocoding prices in 2026

François Andrieux — Fri, 06 Mar 2026 10:00:00 GMT

Here’s a clear overview of what the main geocoding services cost in 2026, and whether anything changed recently. Use the table and the interactive chart below to compare prices at a glance and to simulate your costs. 🙂

Table of contents:

Pricing overview

Roughly what you pay after the free tier (per 1,000 requests, in USD). Free tiers and volume discounts vary; check each provider for exact terms.

Provider	Free tier	Price per 1,000 (after free)	Note
Google Maps	10,000/month	$5.00	Volume discounts; see March 2025 changes below.
HERE	30,000/month	$0.83	Volume discounts; 6% increase from April 2026 for new contracts and renewals.
TomTom	2,500/day (~75k/month)	$0.75	Volume discounts.
Mapbox (Temporary)	100,000/month	$0.75	Temporary results only; no long-term storage.
Mapbox (Permanent)	—	$5.00	Allows indefinite storage of results.
OpenCage	2,500/day (~75k/month)	from ~$0.15–0.17	Subscription-based; volume discounts. Permissive storage.
Nominatim (OSM)	Public API rate-limited	Free	Self-hosting has infra costs.

Many countries also have free or low-cost official APIs (e.g. France's BAN, Spain's CartoCiudad, UK's OS Places under certain schemes). For local addresses, check our country-specific comparisons linked at the end.

Compare costs at your volume

The difficulty is that most providers have different pricing tiers and different free tiers. So you need to know exactly how many addresses you need to geocode to know which provider is the cheapest. Also, prices typically decrease as volume increases, so your per-request cost depends heavily on your total usage.

You can simulate your costs with the interactive chart below. Just select the number of addresses you need to geocode and the chart will show you the cost per provider!

Did prices change?

Google (March 2025): Google replaced the previous $200/month credit with per-SKU free usage (e.g. around 10,000 free billable events per month for the Geocoding API). Volume discount tiers were expanded for high usage. So the effective free tier for geocoding is lower than before, but heavy users can see lower marginal costs at scale. Details: Google Maps Geocoding API guide and Google Maps Platform March 2025 changes.

HERE (April 2026): From April 1, 2026, the HERE Base Plan and all pay-per-transaction Location Services and Data IO increase by 6% for new contracts, renewals, and extensions. Existing contracts are unchanged until renewal. See HERE price increase by 6% in 2026 for details.

Other major providers: TomTom, Mapbox, and OpenCage have kept their published pricing stable into 2026. Our source dates in the repo are October 2025 / January 2026; always confirm current prices on each provider’s site before committing.

How to reduce geocoding cost

Relying on a single premium provider (e.g. Google at $5 per 1,000 requests) can become very expensive at scale. A proven way to cut costs without sacrificing quality is cascading geocoders: use several providers in a defined order, and only fall back to the next when the current one fails or does not meet your criteria.

What is cascading? You define an ordered list of providers (e.g. OpenStreetMap or OpenCage → HERE → Google). For each address, you try the first provider; if that fails or the result does not pass validation, you automatically try the next one, and so on. Cheaper or free providers handle the bulk of easy addresses; premium providers are used only for the harder cases. The result: higher success rates (often 98–99% instead of ~90% with one provider) and lower total cost, because most requests are served by the least expensive option.

Reduce your costs with Coordable cascading geocoding

The diagram below illustrates the idea: send 100% of requests to a free or low-cost provider first (e.g. OSM); only the unresolved share (e.g. 10%) goes to a mid-tier provider (e.g. HERE); and only the remainder (e.g. 4%) hits the premium provider (e.g. Google). You still reach a very high overall geocoding rate (e.g. 99.9%) while paying the premium rate for a small fraction of traffic.

Cascading geocoders: prioritize cheap or free providers, fall back to premium only when needed. Quality and cost scale with each step.

You can implement cascading in your own code (call provider A, then B on failure, etc.) or do it easily with Coordable: choose your providers, define the cascade order and fallback rules, and optionally validate results so only good coordinates reach your database. Either way, the principle is the same: prioritize cheaper solutions and only fall back to premium when it is truly necessary.

Try Coordable to easily implement cascading geocoding for your business.

Price is not everything

Pricing does not always reflect quality. The cheapest option is not necessarily the worst, and some geocoders can match or beat large commercial providers depending on region and data type (addresses vs POIs, local vs global). To see how providers actually perform where you operate, check the best geocoding provider for your country. We have in-depth comparisons for:

Where to go from here

For more detail on a single provider (coverage, rate limits, licensing), see our guides: Google Maps Geocoding API, HERE Geocoding API, Mapbox Geocoding API. For a head-to-head in 2026, see Google vs HERE for geocoding.