Location autocomplete: when to use city, region, country, or address fields

A POI or places search field is different again: it helps users choose businesses, venues, landmarks, institutions, stations, hotels, restaurants, and other named places. Google describes its Places Autocomplete API as returning place predictions such as businesses, addresses, and points of interest, with location bias and restriction options. That breadth is useful for map-connected search, but it can be too broad for a form that only asks "Where are you based?"

Geocoding and reverse geocoding are also separate tasks. A geocoder turns a known address or place description into coordinates. A reverse geocoder turns coordinates into a readable place or address label. They may sit near autocomplete in a maps platform, but they are not the same user-interface problem.

Use a country field for supported markets, billing country, tax handling, compliance workflows, language defaults, and high-level reporting. A country field should usually be structured, not free text. Store a stable country identifier and display name separately, because users may type "United States," "USA," "U.S.," or a localized equivalent.

Use a region or administrative-area field when country is too broad but city is more detail than the product needs. Good examples include sales territory routing, state or province rules, regional marketplace availability, content licensing, and regional analytics.

The main challenge is terminology. "State" is right in some countries and wrong in others. "Province," "county," "department," "region," and "administrative area" can all be correct in different contexts. PlaceField's API exposes parent context through a generic hierarchy[] response shape so integrations do not have to assume every country follows one fixed country, state, city model.

This is the right level for many SaaS signup forms, profile locations, marketplaces, CRMs, communities, job boards, directories, event forms, and discovery filters. A user can answer "Where is your company based?" or "Which city is this listing in?" without giving a home address, office suite, or postal address.

A free-text city field looks simple, but it creates messy data. Users can type abbreviations, alternate spellings, old names, local-language names, or city names without country context. A canonical city autocomplete field can store a stable ID, display label, country, administrative hierarchy, and coordinates when available.

For coordinates, be clear about meaning. A coordinate attached to a city is useful for broad ranking, display, and approximate map placement. It should not be treated as a deliverable address, a legal boundary, a service-area polygon, or proof of a user's exact location.

PlaceField is designed for this non-address use case. The API reference documents city, municipality, state, province, region, and country result types, stable IDs, hierarchy, country data, coordinates when available, language preferences, country restrictions, and geographic bias metadata. For a product overview, see the location autocomplete API, city autocomplete API, and city geocoding API pages.

Address autocomplete fits ecommerce delivery, courier pickup, field-service appointments, ride pickup and dropoff, property submissions, hotel or venue entry, utility setup, insurance quoting, and other workflows where street-level destination affects the outcome.

In those workflows, city autocomplete is under-specified. The user may choose the right city but still omit the postal code, unit number, building entrance, or street number needed for fulfillment. Address autocomplete can help entry, but it is not the same thing as address validation.

Google's Places product family separates Autocomplete from Address Validation, Geocoding, Nearby Search, Text Search, and related capabilities. Its address-form documentation also recommends requesting only the place data fields an application needs, because broad place details can include more data than the form actually uses.

Many product flows only need broad location. A founder directory may need city and country. A CRM may need the customer's market. A freelancer marketplace may need service cities. A job board may need office city or remote-work region. A community app may need nearby members at city level.

This is both a UX issue and a data-minimization issue. Nielsen Norman Group recommends keeping forms short and removing fields that can be omitted, derived, or collected later. The ICO's UK GDPR guidance says personal data should be adequate, relevant, and limited to what is necessary for the stated purpose.

A useful test is simple: what breaks if we do not collect the street address? If the answer is "nothing," choose a country, region, or city field instead. The location field without street addresses guide expands this pattern for signup, profile, marketplace, and CRM forms.

Use PlaceField when you need a structured city, region, administrative area, or country field for an app, form, or backend. Use the location autocomplete API when you want custom frontend or backend control. Use the location autocomplete widget when you want ready-made browser UI. Use the city autocomplete API when the field is specifically city-level.

Do not use PlaceField as a postal address validator, routing engine, reverse geocoder, map UI, or POI search product. That boundary is a strength when your product only needs canonical administrative geography: the field can stay focused on the user's actual task.

The broader lesson is not "always use city autocomplete" or "always use address autocomplete." The right choice depends on the product action. Choose the smallest location unit that supports the workflow, store it in a structured format, and avoid collecting more detail just because an API can return it.