Google Maps API vs. HERE for geocoding (2026)

Last updated: 2026-01-09 | Updated by: Coordable | Sources: Google Maps Platform Pricing, Google Geocoding API Usage & Billing, Google Maps Platform Terms of Service, HERE Developer Terms and Conditions, HERE Coverage Information

Table of contents

If you are choosing a geocoding provider in 2026, the decision is rarely just “who is more accurate?”. In practice, teams switch providers (or regret their first choice) because of pricing at scale, rate limits under load, and especially license terms around storage and how results can be displayed.

This guide compares two top-tier options:

Google Maps Geocoding API (part of Google Maps Platform) and HERE Geocoding & Search (often called “Geocoding & Search API”).

If you want the full deep dives, you can also read our standalone guides: Google Maps Geocoding API guide and HERE Geocoding & Search API guide.

Quick comparison (the parts that usually decide)

This table is intentionally short. It focuses on the constraints and trade-offs that most commonly matter in real products.

Topic Google Maps Geocoding API HERE Geocoding & Search
Best at Maximum global accuracy + best POI coverage Excellent geocoding + strong POIs with competitive pricing
Free tier (typical) 10,000 requests/month 30,000 requests/month
Typical price after free tier $5 per 1,000 (then decreases with volume) $0.83 per 1,000 (then decreases with volume)
Very high volume Down to ~$0.38 per 1,000 (5M+ tier shown in our guide) Often ~$0.66 per 1,000 (5M–10M tier shown in our guide)
Rate limits Published: 3,000 requests/minute (≈50 req/s) Plan-dependent (expect throttling + 429s on bursts)
Storage / caching Strict: 30-day caching limit is a common constraint Limited: caching allowed only under specific conditions; repository building prohibited
Map display restriction Yes: results must be displayed on Google Maps (common ToS constraint) No default lock-in to a single map renderer (still must follow attribution/terms)
When it becomes tricky Bulk geocoding + storing results, or displaying on non-Google maps Bulk geocoding + storing results as a reusable database

If you only remember one line: Google is the “best results, highest constraints” option; HERE is usually “near-top results, easier economics,” but still not a free-for-all for storage.

Introduction: why this comparison matters in 2026

Geocoding is deceptively simple: you send “1600 Amphitheatre Parkway” and you get coordinates back. But once you go from a prototype to production, you start caring about questions like:

Do we need to geocode millions of rows? Can we store results for analytics, deduplication, or CRM enrichment? Are we allowed to display these coordinates on our own maps? What happens during spikes and batch backfills?

Google and HERE both deliver excellent results, but they are optimized for slightly different realities:

Google wins on POI depth and “messy input” resilience, and is often the first choice for consumer apps that rely on places, businesses, and autocomplete. HERE is widely used in automotive/logistics contexts and is attractive when you need high quality without Google’s map-display constraints, and with a pricing structure that’s often friendlier at normal-to-large volumes.

Accuracy and coverage: where each provider excels

Both providers are “premium-tier” for address resolution in most countries. If your inputs are well-formed (street + housenumber + city + country), you will usually get reliable results from either.

Where differences show up is in the long tail:

Google tends to shine when your queries look like real user behavior: partial inputs, missing components, mixed languages, local nicknames, or direct POI searches (e.g., “Starbucks Times Square”). Google’s Street View, user contributions, and business-owner updates give it a uniquely dense POI and business layer in many regions.

HERE is often impressively strong on structured address matching (street + housenumber) and provides a solid ecosystem for search UX (autosuggest/typeahead, discover/browse). In many European markets, HERE performs extremely well for navigation and enterprise use cases.

The practical takeaway: if you are building a product where the “address” is really a place (restaurants, venues, pickup points), Google’s POI advantage can be decisive. If you mainly need reliable address resolution and search UX at scale, HERE may be “close enough” on accuracy while being simpler on cost and map-stack flexibility.

Pricing: understanding the true cost of geocoding

Pricing is one of the easiest areas to misunderstand, because the “per 1,000 requests” number only matters once you account for the free tier and your expected volume.

In our provider guides, the typical tiers used are:

Google includes a first free tier (10,000 requests/month in our Google guide), then a series of volume tiers (for example, $5 per 1,000 for 10k–100k). HERE typically starts with a larger free tier (30,000 requests/month in our HERE guide), then uses a lower unit price (for example, $0.83 per 1,000 up to the multi-million range, with a lower tier beyond that).

Cost examples (rough, but practical)

To make this concrete, here are back-of-the-envelope monthly costs using the tiers described in our guides.

Monthly requests Google (approx.) HERE (approx.)
25,000 $75 FREE
100,000 $450 $58
1,000,000 $3,550 $805

These examples highlight a pattern most teams observe in practice: for typical batch sizes (tens of thousands to a few million), HERE is often materially cheaper.

At very high volumes, Google’s unit price can drop dramatically (in our Google guide, the 5M+ tier is shown at ~$0.38 per 1,000). If your usage is truly in the multi-million range every month, it is worth modeling both providers carefully. But cost is not the only “scale” constraint.

Common pricing pitfall: forgetting that licensing can force re-geocoding

If a provider limits caching (for example, to 30 days), you may have to re-geocode the same rows repeatedly. In that situation, the “per-request” price matters more than you first think, because you cannot amortize your spend over a durable dataset.

Rate limits and performance: what you need to know

Rate limits are not just a developer inconvenience. They shape how fast you can onboard customers, run imports, and recover from incidents.

Google documents a geocoding limit of 3,000 requests per minute (about 50 requests per second). That is enough for many applications, but you still need sensible pacing and retry logic. When you hit limits, expect HTTP 429 errors.

HERE’s limits are described as plan-dependent. In practice, you should assume throttling exists and design for it: request pacing, exponential backoff, and batch job controls that can slow down gracefully instead of failing.

Best practice that applies to both: treat geocoding as a “rate-limited dependency,” not a free-for-all HTTP call. Build queues for bulk jobs, and make sure your product can degrade gently when the provider pushes back.

Licensing and terms: the hidden constraints that matter

Licensing is where many otherwise “correct” architectures get stuck. The same technical workflow (geocode → store → reuse) can be compliant with one provider and explicitly restricted with another.

Google: strict storage and map-display constraints

In many use cases, Google’s terms are the dominant factor:

Caching and storage are commonly constrained (often framed as a 30-day caching window). Map display can also be restricted: using Google geocoding results with a non-Google map renderer is a common red line. Finally, bulk or pre-fetching workflows (especially “build a database once, reuse forever”) can be problematic unless you have the right agreement.

If your product needs a durable geocoded dataset (think CRM enrichment, analytics warehouses, offline operations, deduplication pipelines, or repeat lookups without re-geocoding), Google’s standard terms can become a real blocker.

HERE: more flexible map-stack usage, but still strict about repository building

HERE is often perceived as “more flexible” because you are not automatically tied to a single map renderer. That is frequently true, but HERE is still very explicit about storage and scaling patterns:

On standard terms, you generally cannot build a reusable repository of location assets from cached results, and caching is limited and tied to specific conditions (headers, short-term improvement of end-user experience, etc.).

In other words: HERE may be easier than Google for “geocode → display on my own maps,” but it is still not designed for “geocode once → keep forever → resell/redistribute/serve many users from stored results.”

Practical note for 2026: HERE portal migration

HERE has announced that developer.here.com is being shut down by March 16th, 2026, with users migrating to a newer portal experience. If you are starting an integration in 2026, plan for documentation URLs and account flows to evolve, and keep internal docs flexible.

POI and business data: beyond simple addresses

If your queries often look like “Eiffel Tower”, “McDonald’s Paris”, or “hospital near me”, you are not just geocoding addresses—you are searching a place database.

Google’s major advantage is the breadth and freshness of its POI graph (our Google guide references 200M+ places). That typically translates into:

better coverage for small businesses and consumer venues, richer place metadata (hours, ratings, reviews), and stronger behavior on “natural language” place queries.

HERE also provides strong POI discovery and is widely used in navigation contexts. If you need brand/category search, typeahead, and reliable places for logistics workflows, HERE can be a great fit—especially when paired with an address-first UX (user picks a suggestion, then you confirm location).

Address parsing intelligence: handling real-world messiness

In clean datasets, both providers do well. The difference is how they behave when your inputs are messy: typos, missing country, abbreviations, extra noise, or partial strings typed into a form.

Google is well known for robust parsing of imperfect input and strong autocomplete/suggestions across many countries, which is one reason it is so common in consumer applications.

HERE is also strong here, and its multiple endpoints (autosuggest/typeahead, discover/browse, geocode/reverse) are designed for building good search UX. If your team wants more control over the “search journey” (suggest → choose → geocode), HERE can feel very ergonomic.

The best practice is the same either way: treat parsing as a product feature, not a backend detail. A good capture UX can reduce ambiguity and cost, because a “bad query” often leads to retries, manual review, or downstream errors.

Making the right choice: a practical decision framework

Here is a human way to decide—based on what usually breaks first.

Choose Google when you need the absolute strongest global POI layer, and your product is compatible with Google’s licensing constraints (especially around map display and storage). This is common for consumer apps, marketplaces, and experiences where “place search” is a primary feature.

Choose HERE when you want top-tier geocoding and POI search, but you also care about:

keeping your mapping stack flexible, controlling spend at typical-to-large volumes, and building enterprise workflows (logistics, routing, operations) without being tied to a single map renderer by default.

If you are unsure, the most reliable approach is to test both on your own data. Accuracy differences are often smaller than teams expect; licensing and economics differences are often larger.

Best practices and common pitfalls (for both)

The goal here is not to “scare you off,” but to save you time. Most geocoding pain is predictable.

Best practices

Start with clean inputs: normalize country, split address components when available, and standardize common abbreviations. Use retries with exponential backoff, and throttle batch jobs intentionally. Keep an audit trail for difficult records (what you sent, what you got back, what confidence signals you used).

Common pitfalls

Relying on caching without reading licensing terms; geocoding with one provider and displaying on another map; batch-geocoding entire databases without designing for rate limits; and assuming that “one request = one definitive truth” when your inputs are incomplete.

Conclusion

Google and HERE are both excellent. Your “best” choice depends less on raw accuracy and more on what you need to do after you geocode: store results, reuse them, display them, and scale reliably.

If you want help comparing providers on your own dataset (and understanding why some records fail), Coordable combines AI address cleaning with multi-provider analytics so you can make the decision with evidence, not guesswork.

Last updated: 2026-01-09 | Updated by: Coordable | Sources: Google Maps Platform Pricing, Google Geocoding API Usage & Billing, Google Maps Platform Terms of Service, HERE Developer Terms and Conditions, HERE Coverage Information

Disclaimer: This comparison is for informational purposes. Always verify current pricing, rate limits, and licensing terms in the official provider documentation and your account agreement.