← Back to blog

Why IP Geolocation City Accuracy Is Limited

Why IP Geolocation City Accuracy Is Limited

IP geolocation city accuracy is limited because an IP address records where a network is registered and routed, not where a device physically sits, so country-level answers are usually dependable while city-level answers are best-effort estimates. Understanding that difference lets you decide which decisions an IP lookup can safely drive.

Why country is reliable and city is not

IP address space is allocated in a hierarchy. Regional internet registries hand blocks to organizations, and those organizations register the country in the allocation records. Routing adds a second, independent witness: the network announcing a block in BGP is identifiable by its ASN. The two sources usually agree on country because large networks operate within defined national footprints, and a block rarely changes country. That is why country is the field most services get right most of the time. It is still not perfect, since the registration country can differ from where the infrastructure sits, and a multinational company may register a block in its headquarters country and use it elsewhere. The ASN lookup shows the owner and registration country of the network behind an address, which is useful for reasoning about those cases.

City is a different kind of claim. No registry publishes where an address is used, so every city value comes from inference: registry hints, latency measurements, user-submitted corrections, and commercial or open datasets that combine them. Each method has failure modes, and the inferences are strongest for fixed broadband in dense areas and weakest for everything else.

What pulls city results off target

Several common situations break the link between an address and a place:

  • Mobile networks. Traffic from many devices exits through a gateway that can be far from the handset, and the address may be shared by thousands of subscribers, so the city shown is often the gateway's region.
  • Centralized routing. An internet provider may route a whole region through a single point of presence, so users in several towns appear in one city.
  • VPNs, proxies and Tor. The visible address belongs to the exit server, which is in a different place from the user by design.
  • Cloud and hosting addresses. A server in a datacenter is where the datacenter is, regardless of the application's audience.
  • Reassigned blocks. Blocks move between providers and regions faster than location data is corrected, so records go stale.
  • IPv6. Coverage and corrections are generally thinner for newer address space; we cover this in IPv6 geolocation accuracy.

Commercial databases and free ones alike face the same underlying problem, because they are all estimating from indirect evidence. Differences between providers are real but they are differences of degree. When two providers disagree on a city, neither is obviously right.

Designing around the gap

The practical rule is to match the precision of the decision to the precision of the signal. Country is suitable for content licensing, tax and compliance defaults, language defaults and rough routing. City is suitable for soft personalization, such as a pre-filled weather location, that the user can correct in one click. It is not suitable for anything where a wrong answer is costly: do not deny service, assert someone's address or make legal determinations from a city guess.

Use network context to judge how much to trust the city. If an address belongs to a datacenter or a VPN, the location describes the server, and ipto's lookup flags this with is_datacenter, is_vpn and is_tor, which the VPN and proxy checker shows on its result page. If the ASN belongs to a mobile operator, expect the city to describe the carrier's gateway. The company lookup and IP whois pages show the organization that holds the block, a good sanity check on whether an address is residential, corporate or infrastructure.

On the product side, ask when precision matters. The browser's own geolocation permission is the right tool for an exact position, and an address typed by the user is better still. ipto's weather and places pages follow this pattern: they request the browser location first and fall back to the approximate IP location only when permission is declined. Treat the IP estimate as a default that the user can override.

Using ipto for coarse location

The ipto IP lookup returns country, city, ASN, organization and the flags above, and datasets refresh daily, with threat feeds refreshing every 6 hours. It is free with no signup for 1,000 requests per day, so you can compare results against your own ground truth, such as addresses from users who have told you their location, and measure how often city matches in your own traffic. That measurement is worth more than any published accuracy claim. For more on matching the type of data to the job, read IP intelligence versus a geolocation API, and see the API documentation for field definitions.

Straight answers

Country comes from registry allocations and routing records that change rarely, while city has to be inferred from indirect evidence because no registry publishes where an address is used. Inference is easily thrown off by mobile gateways, VPNs and centralized provider routing.
No. IP geolocation gives an approximate area, often only to the nearest city or the provider's point of presence, and it cannot identify a street address or a person. Use browser geolocation permission or user-entered input when precise location matters.
Use the city only for soft defaults that a user can correct, rely on country for decisions such as licensing, and check flags like VPN, Tor or datacenter, since those addresses describe a server rather than a user.
← Back to blog