Every country’s dropdown on a signup form is a small tax. The user scrolls a list of 195 options, picks one, and you store a value they may have selected carelessly. Meanwhile the request that carried their form submission already told you roughly where they sat, which network they used, what currency they spend, and what time it was on their clock. You asked for something you already had.
This is the case for treating IP geolocation as a default input rather than an afterthought. Not as a replacement for user intent, and not as an identity signal, but as the starting position your interface takes before the user says anything.
The mechanics are simpler than most teams assume. Regional internet registries publish which organisation holds which block of addresses. BGP routing tables show where those blocks are announced from. Provides layer network measurement, ISP records, and submitted corrections on top of that to narrow the estimate further. A lookup takes the requesting IP address, resolves it against those sources, and returns a location estimate along with the network context that came with it.
What you get back is more than a place name. Ip geolocation services such as ipwhois.io return the full set in a single JSON response: continent, country, region, city, coordinates, plus the ASN and ISP behind the address, the local timezone with its UTC offset, the local currency and its exchange rate, and flags marking whether the address belongs to a proxy, VPN, Tor exit node, or hosting provider. That last group matters more than most product teams expect, and I will come back to it.
The free tier on most providers, ipwhois.io included at 1,000 requests per day with no key required, is enough to run this experiment against your own traffic before anyone signs a contract. Pull a week of production IPs, resolve them, and compare the result against the country values your users actually selected. The gap is usually instructive.
What an IP address genuinely resolves to
Be precise about accuracy, because vendors rarely are and product managers rarely ask.
Country resolution is close to being solved. Published accuracy benchmarks across the industry put country-level resolution at roughly 99.8%, and every serious provider sits in that band, because country allocation is a matter of registry record rather than inference. If a provider cannot tell you the country, the address itself is unusual.
Below the country, confidence drops sharply. Region and state resolution runs around 80% for United States addresses. City drops to roughly two thirds, and the definition of “correct” at that level is generous: the estimate counts as a hit if it lands within a 50 kilometre radius of the right city. Outside the United States and Western Europe, city accuracy falls further. Mobile networks are worse again, because carriers route large subscriber pools through a small number of gateways that may sit hundreds of kilometres from the handset.
The practical rule: country is a fact you can build on. Region is a hint. City is a guess. Coordinates are a centroid, not a position, and the frequent appearance of a geographic midpoint as someone’s apparent address is a well-documented consequence of treating them otherwise.
Design around that hierarchy and IP data becomes reliable. Design against it and you will ship a feature that fails for a quarter of your users in ways they will not report.
Four jobs it does well
Presetting forms. Country, and therefore phone prefix, address format, postal code validation rules, and date order. The user still sees the field and can change it. You have removed a decision, not made one for them.
Currency and pricing display. Showing prices in the currency someone spends removes a mental conversion step before they reach the price itself. Currency and exchange rate arrive in the same lookup as the country, so this costs no additional call.
Timezone handling. Scheduling interfaces, delivery windows, notification timing, and any “we will call you between” promise. Browser timezone from Intl.DateTimeFormat().resolvedOptions().timeZone is usually the better source client side, but IP timezone covers server-rendered pages and email, where no browser context exists.
Network risk triage. The proxy, VPN, Tor, and hosting flags tell you what kind of connection you are dealing with. A residential ISP address behaves differently from a datacentre address, and a datacentre address hitting your signup endpoint at three in the morning is a different proposition from a Comcast subscriber doing the same. This is where the ASN and organisation fields earn their place. Blocking on these flags is almost always wrong. Adjusting what you require next is almost always right.
Where it breaks, and what to do about it
Four conditions degrade IP location, and all four are becoming more common.
Carrier grade NAT. IPv4 exhaustion means thousands of subscribers now share a single public address. Mobile networks and many fixed-line ISPs in South and Southeast Asia operate this way. The address is real; the location behind it covers a region rather than a household.
Privacy relays. Apple’s iCloud Private Relay routes Safari traffic through two hops and presents an egress address from a pool. Apple publishes a geo feed mapping those addresses to an approximate region, and providers that ingest it return a usable country. Providers that do not will return the relay operator’s location instead, which may be a different country entirely.
Corporate VPN and split tunnelling. An employee in Dhaka working through a London office VPN resolves to London. The address is correct and the person is not there.
Consumer VPN. Roughly 30% of internet users report using a VPN at some point, and a share of those keep one running by default. Their apparent country is a preference, not a location.
The response to all four is the same: treat the result as a prior, not a verdict. Set the default, show it, and make the correction path one click. A country selector that opens with the right answer already chosen serves the 90% and costs the other 10% nothing. A country selector that has been replaced by a hard geographic assumption serves nobody well.
Where the stakes are higher, such as tax jurisdiction, licensing, or age gating, IP data becomes one input among several rather than the decision itself. Combine it with billing address, phone country code, declared country, and payment instrument BIN. Agreement across signals is a strong result. Disagreement is the signal that a human or a step-up check should look at the case.
Implementation notes that save rework
Resolve at the edge or on first request, then cache the result on the session. A per-page-view lookup burns quota and adds latency for a value that does not change within a visit.
Never block rendering on the lookup. Serve a sensible default, resolve asynchronously, and update the fields that matter. Providers advertising 50 millisecond response times are measuring their own infrastructure, not the path from your server through a congested transit link.
Handle the empty case explicitly. Private IP ranges, localhost during development, malformed X-Forwarded-For headers behind multiple proxies, and addresses with no registry data all return nothing useful. Decide what your interface does when the answer is unknown, and test that path rather than discovering it in production.
Trust the right header. If you sit behind a CDN or load balancer, the client IP is in X-Forwarded-For or a vendor-specific header, and the leftmost entry is user-supplied and spoofable. Read the entry your infrastructure appends, not the first one in the list.
On the privacy side, an IP address is personal data under GDPR, and processing it requires a lawful basis. Legitimate interest generally covers fraud prevention and localisation, but the obligation to document that assessment, disclose the processing in your privacy notice, and apply a retention period is real. Deriving location for the current request and discarding the raw address is a materially easier position to defend than storing IP logs indefinitely.
What to measure
Ship it behind a flag and watch four numbers.
Form completion rate on any step where you preset a value. Correction rate, meaning how often users override your default, which tells you your real accuracy on live traffic rather than the vendor’s claimed accuracy. Checkout conversion by currency display, split between localised and base currency. Support ticket volume mentioning the wrong country or wrong currency, which catches failure modes your analytics will not.
If the correction rate on country runs above 10%, you have a data quality problem or a traffic mix heavy in VPN and relay users. Either way, that number tells you whether to expand the pattern or pull it back.
The underlying point
Asking users for information you can already derive is not neutral. It adds steps, it invites careless answers, and it signals that your product has not thought about them. Deriving it and presenting it as an editable default respects both the user’s time and their right to correct you.
IP geolocation is not precise, and treating it as precise is how teams get burned. Treated as a well-informed opening position, it removes friction from the parts of a product where friction is most expensive.
