An IP address maps to a location because geolocation providers record where each block of addresses is used. The address itself contains no coordinates. When you look up an IP, you query a database, and the database holds an estimate. That estimate is usually right at the country level, often right at the city level, and wrong at the street level almost every time.
Why an IP maps to a location at all
IP addresses are handed out in a hierarchy. IANA allocates large blocks to five regional registries: ARIN for North America, RIPE NCC for Europe, APNIC for Asia Pacific, LACNIC for Latin America, and AFRINIC for Africa. Each registry allocates smaller blocks to ISPs, hosting companies, and large enterprises. Those records are public. Query them through WHOIS or RDAP and you see which organization holds a block and which country it registered in.
That hierarchy gives geolocation its foundation. If ARIN allocated a block to a cable ISP in Texas, addresses from that block sit in Texas most of the time. ISPs then assign addresses to customers by region, because routing works better when nearby customers share address space. The structure was built for routing. Location leaks out as a side effect.
How providers build the databases
Registry records only get you to a country or an ISP's headquarters. Commercial providers such as MaxMind, IP2Location, and IPinfo layer more signals on top:
- ISP data feeds. Some ISPs share which regions use which address blocks.
- Latency measurement. Providers ping an IP from probe servers around the world. Round-trip times bound how far away it can sit, since packets cannot outrun the speed of light in fiber.
- GPS correlation. Mobile apps that collect device location also see your IP. Aggregated at scale, this ties address blocks to real coordinates.
- User corrections. Providers accept fix requests when a lookup lands in the wrong city.
Each provider merges these signals, scores its confidence, and publishes updated databases daily or weekly. When your ISP reshuffles its address pool, the databases catch up on a later update. That lag explains why a new connection can show the wrong city for weeks.
How accurate it is
Accuracy drops fast as you zoom in:
- Country: 95 to 99 percent. Registry data alone nearly guarantees this.
- City: roughly 55 to 80 percent, depending on the provider and the country. Dense, well-mapped networks in the US and Europe score higher. Mobile networks score lower.
- Street address: never. No IP database can identify a household. The coordinates in a lookup result point to a city center or an ISP facility.
Several things break the mapping. Mobile carriers use carrier-grade NAT, so thousands of phones across a wide area share one public IP. VPNs and proxies show the server's location instead of yours. Corporate networks route branch offices through one central egress, so an employee in Denver can appear to browse from New Jersey.
Trusting the numbers too much has real consequences. MaxMind once used the coordinates of a Kansas farm as its default point for "somewhere in the United States." For years, people traced scammers and stolen phones to that farm and harassed the owners, until MaxMind moved the default into a lake. Treat coordinates as a label for a region, never as a pin on a door.
How to find the location of an IP address
You have three practical options:
- Use a web lookup. Sites like ipinfo.io and iplocation.net query multiple databases. Compare two or three results before you trust one. If they agree on the city, believe it. If they scatter, believe only the country.
- Use the command line. Run curl ipinfo.io/8.8.8.8 and you get back the city, region, country, and owning organization as JSON. For the registry's own record, run whois against the address or use RDAP at rdap.org.
- Check your own IP. Search for "what is my IP" and open one of the lookup sites. If the city is wrong, your ISP's block was recently remapped or you sit behind carrier-grade NAT.
Read the whole result, and weigh the owning organization above the coordinates. An IP registered to Amazon or DigitalOcean belongs to a server or a VPN endpoint, whatever city the database prints next to it.
Where DNS fits in
Geolocation and DNS intersect in two places you will notice. First, GeoDNS: authoritative servers, including those run by Valla DNS, can look at where a query comes from and answer with the IP of a nearby server. That is how a CDN sends you to Frankfurt instead of Oregon. Second, your resolver can distort the picture. If you use a public resolver far from home, sites may geolocate the resolver instead of you and serve the wrong region. EDNS Client Subnet fixes this by forwarding part of your IP with the query, at some cost to privacy.
So when a site loads in the wrong language or a stream insists you are in another country, check the chain: your IP's database entry, your VPN, and your DNS resolver. One of the three is telling the site a location story, and you now know how each one builds it.