Skip to main content

​
HERE Geocoding vs Google Maps Geocoding

Choose HERE when your workload is address resolution at volume, when you need per-field confidence rather than a single match level, or when batch geocoding is a meaningful fraction of your bill. Choose Google when your product discovers places — businesses, hours, reviews, categories. Its place database is better. Not marginally. Categorically. Most systems need both, and the right architecture says so out loud.

​
Comparison scope

Geocoding, reverse geocoding, autocomplete, and place discovery. Not routing (see HERE Routing vs Google Maps), not rendering, not platform-level ecosystem fit (see HERE vs Google Maps). HERE’s capability is delivered through Geocoding & Search v7, which consolidated the former Geocoder API 6.2 and Places/Search APIs. Those legacy APIs are in maintenance and should not be used for new work.
HERE Geocoding & Search v7 uses per-endpoint hosts, not one base URL:
EndpointHost
/v1/geocodegeocode.search.hereapi.com
/v1/revgeocoderevgeocode.search.hereapi.com
/v1/autocompleteautocomplete.search.hereapi.com
/v1/autosuggestautosuggest.search.hereapi.com
/v1/discoverdiscover.search.hereapi.com
This surprises teams building a single client. Verified July 2026 against HERE Geocoding & Search documentation.

​
Decision summary

RequirementBetter fitWhy
Street address → coordinatesComparableBoth are strong. Test on your addresses
Per-field match confidenceHEREfieldScore breaks down confidence by address component
Distinguishing rooftop from interpolatedHEREhouseNumberType: PA vs interpolated is explicit
Structured query inputHEREqq accepts typed fields; avoids free-text ambiguity
Business POI discoveryGooglePlace database, hours, reviews, photos
Consumer autocompleteGoogleTypo tolerance and ranking from enormous query volume
Batch geocoding at millions of recordsHEREBatch API v7 is a job API with a documented lifecycle
Address deliverability validationNeitherUse a postal-authority validation service
Routing-aware coordinatesHEREaccess returns the road-network entry point separate from position
Cost at production volumeDependsOn mix, tier, batching, caching. Not on rate card

​
Where HERE is stronger

​
Per-field confidence scoring

This is the difference most evaluations miss, and it is the one that matters for data quality. HERE returns a scoring object on every geocode result: 
"scoring": {
  "queryScore": 0.97,
  "fieldScore": {
    "country": 1,
    "city": 1,
    "streets": [1],
    "houseNumber": 1,
    "postalCode": 0.82
  }
}
Response abbreviated. Source: HERE geocode documentation. queryScore is overall match quality. fieldScore tells you which component was uncertain.
A result with queryScore: 0.95 and fieldScore.houseNumber: 0.4 matched the street confidently and the house number poorly. That is a different operational risk than fieldScore.postalCode: 0.8 — one produces a failed delivery, the other does not.A single aggregate confidence number cannot express this. Store fieldScore.
Google returns location_type (ROOFTOP, RANGE_INTERPOLATED, GEOMETRIC_CENTER, APPROXIMATE) and partial_match. Useful, coarser.

​
Rooftop versus interpolated is explicit

HERE returns houseNumberType, with PA indicating a point address and interpolated indicating a position estimated along a street segment. An interpolated address may be tens of metres from the actual building. For last-mile delivery that is the difference between the right door and the neighbour’s. Persist this field. A system that stores coordinates without it cannot distinguish a surveyed rooftop from an arithmetic estimate.

​
access versus position

HERE returns two coordinates per result:
  • position — the location of the address itself
  • access — the point on the road network where a vehicle would arrive
For routing to an address, access is the correct target. Routing to position may route to the geometric centre of a building, or to a point separated from the road by a car park. Google’s geocoding response does not distinguish these. This is a small, specific, real advantage for fleet and delivery systems.

​
Structured queries (qq)

HERE accepts either free-text (q) or a structured query (qq) with typed fields: qq=street=rue de bale;city=Strasbourg;postalCode=67100;country=FRA For validating user-entered addresses, structured input outperforms free text plus a types filter.
Do not send both q and qq in the same request. HERE’s own developer guidance notes that mixing them produces inconsistent queryScore values. Pick one.

​
Batch geocoding architecture

HERE’s Batch API v7 is a job API: create → start → poll status → retrieve results → retrieve errors → delete. It is asynchronous by design, cheaper per record, and built for millions of rows. Three response codes routinely misread as failures:
ResponseMeaning
429 on job startConcurrency limit reached. Queue
204 on errors endpointZero errors. Not a failure
404 on resultsJob has not succeeded yet
See High-Volume Geocoding.

​
Where Google is stronger

​
Place and business data

For business names, opening hours, reviews, photos, and category coverage, Google’s data is categorically better than HERE’s.Placematic sells HERE. We would rather you know this before a migration than after.
If your product answers “what’s a good restaurant near me,” that surface belongs on Google. HERE Geocoding & Search v7 substantially improved POI coverage over its predecessors, and it still is not competitive with Google’s business database.

​
Consumer autocomplete

Google’s ranking, aliasing, and typo tolerance reflect consumer query volume HERE does not have. For a consumer search box, this is decisive. For a street address field — checkout, dispatch, delivery — HERE’s /autocomplete is purpose-built and competitive.
/autocomplete and /autosuggest are not synonyms and this is a common integration error.
  • /autocomplete — completes structured address input. Forms, checkout, delivery.
  • /autosuggest — broader discovery. Returns addresses, POIs, and categories. Handles misspellings.
  • /discover — actual place results for a query. This is the endpoint for “find restaurants,” not /geocode.
Source: HERE developer best practices.

​
Ecosystem

More engineers have integrated Google’s geocoder. This is a real cost in your engineering budget.

​
Low volume

Below roughly ten thousand geocodes per month, both are effectively free. Migration engineering exceeds the saving.

​
Where the difference is commercial or operational

​
Caching and storage terms

Read your contract’s caching and storage terms before designing a permanent geocode cache. Both vendors place restrictions on retaining geocoded coordinates, and those restrictions differ by platform, by plan, and over time.We will not summarize them here because they change and because a summary that is wrong is worse than no summary. Verify with your account manager, and get the answer in writing.
This matters architecturally. A geocode cache is the single largest cost lever available — see Caching Geocoding Results — and its permissibility is a contract term, not an engineering decision.

​
Pricing

We will not publish a savings percentage.Cost depends on API mix, monthly volume, region, contract terms, billing SKU, batching, and caching. These span more than an order of magnitude.
Structurally:
  • Both bill per request for real-time geocoding
  • HERE’s Batch API prices differently from real-time; latency-tolerant work belongs there
  • Google bills autocomplete on a session-token model where sessions are used; HERE bills per request. This means the meters do not translate. A keystroke-level comparison and a session-level comparison are different measurements.
  • Free bundles are per-API and do not pool
Current rates: Google Maps Platform pricing · Placematic pricing calculator.

​
Why “more accurate” is not a number

Any vendor claiming a universal geocoding accuracy percentage is describing a benchmark on a dataset that is not yours.
Geocoding accuracy varies by:
  • Country and region. A platform strong in Germany may be weak in Indonesia.
  • Urban versus rural. Rooftop match rates diverge sharply.
  • Address type. Apartments, PO boxes, rural routes, new-build estates.
  • Input quality. Your own data’s normalization determines much of the result.
  • What “accurate” means. Match rate? Positional error? Rooftop fraction? These optimize differently.
A geocoder that resolves 97% of US urban addresses to rooftop may resolve 60% of your rural service-area addresses to a street centroid. Both statements can be true of the same platform. Neither we nor any vendor can tell you which is more accurate for your data. We can tell you how to find out.

​
How to evaluate with your own data

Run this before you decide. It takes a day. Assemble a representative set. 1,000 addresses minimum, drawn from your actual data — not a curated list. Deliberately include:
  • Urban and rural, in your operating regions
  • Apartments, units, and suites
  • Rural routes and non-standard formats
  • New-build addresses (under two years old)
  • Addresses that have previously failed delivery
  • Deliberately misspelled and truncated variants
  • Every country you operate in, weighted by volume
Establish ground truth. For a subset — 100 is enough — obtain verified coordinates. Site surveys, driver-confirmed delivery GPS, or parcel-level data from a local authority. Measure four things separately:
MetricDefinition
Match rateFraction returning any result
Rooftop fractionHERE: houseNumberType: PA. Google: location_type: ROOFTOP
Positional errorDistance from ground truth, reported as a distribution — median, p90, p99 — not a mean
Confidence calibrationAmong results the platform scored highly, how many were actually correct?
Confidence calibration is the metric almost nobody measures and the one that determines data quality.A geocoder with a lower match rate but well-calibrated confidence is more useful than one with a higher match rate and confidence scores that do not predict correctness. The first lets you route uncertain records to an exception queue. The second silently corrupts your database.Plot correctness against queryScore (HERE) and against location_type (Google). A well-calibrated geocoder produces a monotonic curve.
Test the batch path separately. Real-time and batch may return different results. If your production workload is batch, benchmark batch. Forecast cost from actual call counts, pulled from logs. Not estimates. Apply caching and deduplication to both platforms before comparing — otherwise you are comparing your inefficiency on two rate cards.

​
Architecture implications

Caching is platform-independent and dominates the bill. Normalize, deduplicate, cache permanently, invalidate on events rather than on a TTL. This halves most geocoding bills before any vendor decision. See Caching Geocoding Results. Store the confidence structure, not just coordinates.
Storing a coordinate without its confidence score converts a probabilistic estimate into a fact. Every downstream consumer treats it as truth. A low-confidence fallback silently corrupts revenue maps, routes vehicles to centroids, and produces failed deliveries.
Persist: coordinates, access point, normalized address, queryScore, fieldScore, houseNumberType, resultType, geocoded_at. Autocomplete is a debouncing problem, not a vendor problem. Undebounced, it bills once per character typed. 200–300ms. Per-endpoint hosts complicate a single HTTP client. Minor, but it affects connection pooling and any allowlist your security team maintains.

​
Migration mapping

GoogleHERENotes
Geocoding APIGET geocode.search.hereapi.com/v1/geocodeq for free text, qq for structured. Not both
Reverse Geocoding APIGET revgeocode.search.hereapi.com/v1/revgeocodetypes=area filters to admin areas
Places Autocomplete/v1/autocomplete (addresses) or /v1/autosuggest (places)Two endpoints, not one
Places Text Search / Nearby/v1/discoverNot /geocode
Place Details/v1/lookup by HERE IDStore the ID
—POST /v1/multi-revgeocodeBatch reverse geocoding in one request
location_typehouseNumberType + resultTypeDifferent taxonomies. Do not map naively
partial_matchqueryScore + fieldScoreRicher. Rebuild your quality logic
Semantic differences: Coordinate order. HERE returns {"lat": ..., "lng": ...}. GeoJSON is [lng, lat]. Two coordinates per result. position and access. Decide which your system means. No universal confidence threshold. A queryScore of 0.9 does not mean what a Google partial_match: false means. Recalibrate your thresholds against your own ground truth before cutover. Do not port the number. Batch is a job lifecycle. Not a bulk endpoint. See Google Migration Architecture.

​
Cost model

What creates billable activity:
  • One call per real-time geocode or reverse geocode
  • One call per autocomplete request — which is per keystroke unless debounced
  • Batch records, priced separately from real-time
  • Reverse-geocoding every GPS packet, which is 648,000 calls a day for 200 vehicles on a 10-second interval
Request multiplication risks: Undebounced autocomplete. Reverse geocoding on packet ingest rather than on stop detection. Re-geocoding a stable customer address on every order. Looping single reverse-geocodes instead of POST /multi-revgeocode. Batching opportunities: anything written to a database rather than rendered to a screen. Caching implications: the single largest lever, subject to your contract’s storage terms.

​
Common decision mistakes

Comparing per-1,000 rates. Close at entry level. Meaningless. Accepting a universal accuracy figure. Including ours. Comparing mean positional error. Report the distribution. p99 is where failed deliveries live. Not measuring confidence calibration. Migrating a consumer place-search feature to HERE for cost reasons. The feature regresses. Users leave. Using /geocode for place search. That is /discover. Confusing /autocomplete with /autosuggest. Sending q and qq together. Discarding fieldScore and houseNumberType. Routing to position instead of access. Porting confidence thresholds across platforms. Designing a permanent cache without reading the contract’s storage terms. Migrating before caching and deduplicating. You may be migrating waste.

​
Choose HERE when

  • Address resolution at volume is your workload
  • You need per-field confidence to drive an exception queue
  • Rooftop versus interpolated must be distinguishable
  • You route to addresses and need the road-network access point
  • Batch geocoding is a meaningful fraction of your bill
  • You already license HERE for routing and can consolidate

​
Choose Google when

  • Your product discovers businesses, and hours, reviews, or categories matter
  • Consumer autocomplete quality is a product differentiator
  • Your volume is low enough that migration engineering exceeds savings
  • Ecosystem familiarity and hiring are material constraints

​
The architecture most teams land on

HERE for address resolution, batch geocoding, and routing. Google for consumer place discovery and business search. Two vendors, each doing what it is good at. Document that as a decision before someone frames it as a failed migration.

Geocoding and Search

Endpoint selection, confidence scores, and the caching that halves the bill.

Address Validation

Why geocoding and deliverability validation are different products.

Caching Geocoding Results

Normalization, invalidation, and the privacy question.

High-Volume Geocoding

Millions of addresses, queues, idempotency, and what to monitor.
Also: Batch Geocoding · Reverse Geocoding · Points of Interest · HERE vs Google Maps

​
Sources

HERE Google Placematic Verified July 2026. Endpoint hosts, response fields and pricing change; verify against primary sources.
Need to compare these platforms with your own request mix? Placematic can help you run a technical and cost evaluation using representative routes, addresses and production volumes. Placematic is an official HERE Technologies reseller and implementation partner. Cost Reduction Audit.