The honest answer: country yes, city maybe, street address never
When you use an IP lookup tool and see a city name next to your IP address, it is worth understanding exactly what that number means — and what it does not.
IP geolocation accuracy varies dramatically depending on what level of precision you are measuring:
- Country level: ~95% accurate. For most IPs, determining the country is reliable. This is the data point that geo-blocking systems, streaming services, and compliance tools actually rely on. - Region/state level: ~80% accurate. Less reliable, particularly for countries with centralised ISP infrastructure. - City level: 50–80% accurate. This is where most tools overstate their precision. The "city" shown is often the nearest city to your ISP's infrastructure, not the city you are physically in — which can be dozens or hundreds of kilometres off. - Postal code or street address: not possible from IP alone. Any tool claiming street-level IP geolocation is either using supplementary data (account info, GPS, other tracking) or misleading you.
These figures come from independent audits of geolocation databases and are consistent across the major providers (MaxMind, IP2Location, ipinfo.io). The numbers vary by country and ISP type — mobile networks and corporate IPs are significantly less accurate, as covered below.
How does IP geolocation actually work?
IP geolocation does not use GPS. It does not have access to your device's location services. It makes an educated inference based on network infrastructure data.
There are three main methods:
1. Registry data When an IP address block is allocated, the regional internet registry (ARIN, RIPE, APNIC, etc.) records the country and organisation it is assigned to. This is public data, and it is the basis for country-level geolocation. It is highly accurate because the registry records are authoritative — but they only record who *owns* the IP block, not where individual users connecting through that block are located.
2. Network routing analysis Geolocation companies run probes that measure network latency from known locations to IP addresses. If an IP consistently responds in 5ms from Frankfurt and 150ms from New York, it is probably in Frankfurt. This triangulation improves city-level accuracy but has error margins that grow with ISP network complexity.
3. User-submitted and commercial data Some databases incorporate data from users who have voluntarily reported their location, from ISP cooperation agreements, or from proprietary datasets. This improves accuracy for well-covered regions and large residential ISPs, but coverage is uneven globally.
Geolocation databases are rebuilt continuously — MaxMind's GeoIP2 database, one of the most widely used, is updated daily. But the underlying challenge is structural: the IP address tells you about a *network connection*, not a *physical location*. Those are related but not the same thing.
Why is my IP location showing the wrong city?
This is the most common question people ask after checking an IP lookup tool and seeing a location that does not match where they are. There are several specific reasons it happens:
ISP infrastructure routing Your ISP may route your traffic through infrastructure in a different city — sometimes a different region entirely. If your ISP's nearest exchange point is in a city 100 km away, geolocation databases may resolve your IP to that city because that is where the network infrastructure is registered, even though you are sitting somewhere else entirely.
This is the most common cause of city-level errors for residential broadband users. A user in a rural area may consistently see a major nearby city in IP lookups — not because the data is wrong, but because their traffic genuinely enters the internet backbone through that city's exchange.
ISP address reuse Large ISPs assign IP addresses dynamically and reuse them across wide geographic areas. A block of IPs assigned to "London" in a registry may in practice be given to customers anywhere in the country. Geolocation databases try to correct for this, but the underlying assignment data is ambiguous.
Corporate and institutional networks If you are connecting from a company network, university, or government institution, your traffic may route through a centralised network hub regardless of your physical location. The geolocation resolves to the hub, not you. Someone in the Edinburgh office of a company whose IT infrastructure is in London will show as London.
Recently reassigned IP blocks When large IP blocks are sold or reallocated between ISPs, geolocation databases take time to catch up. An IP that belonged to a German ISP last year and was sold to a French operator may still resolve to Germany in older databases. Lookup tools that use updated databases will be more accurate; those using cached or outdated data will not.
Why VPNs and mobile networks make geolocation less accurate
Two specific connection types reliably produce inaccurate IP geolocation results:
VPNs When you connect through a VPN, the IP address visible to websites and lookup tools belongs to the VPN server, not to you. A VPN server in Amsterdam will show an Amsterdam location regardless of where you physically are. This is intentional from a privacy perspective — it is the VPN working correctly — but it means any geolocation result for a VPN IP is describing the server's location, not the user's.
VPN provider IP ranges are often identified as such by geolocation databases (marked as "hosting" or "VPN" rather than "residential"). If you see your ISP listed as a VPN provider name on myipco.com, your VPN is routing correctly.
Mobile networks Mobile carriers use Carrier-Grade NAT (CGNAT) — many users share a single public IP, and that IP may be assigned to infrastructure far from the actual users. Additionally, mobile networks route data differently from fixed broadband: your phone's data might enter the internet backbone through a different city depending on network load, time of day, and which tower you are connected to.
City-level accuracy for mobile IPs is considerably worse than for residential broadband — some analyses put it below 40%. Country-level accuracy remains high. If you are checking your IP on mobile data and the city is wrong, this is expected behaviour, not a data error.
For more on how VPNs affect your visible IP, see what is a VPN and how does it work.
When IP geolocation is accurate enough — and when it is not
Whether IP geolocation is "accurate enough" depends entirely on what it is being used for. The same 75% city accuracy that frustrates a user trying to confirm their own location is perfectly adequate for many practical applications.
Where it works reliably: - Geo-blocking by country — streaming services, software licensing, compliance checks. Country-level accuracy (~95%) is sufficient. - Approximate traffic analytics — understanding that most visitors come from the US, Germany, and Japan does not require city precision. - Fraud detection as one signal — if a user account was created in Spain and suddenly appears from a Nigerian IP, the country-level flag is meaningful even without precise city data. - Ad targeting by country or broad region — works at the accuracy level IP geolocation reliably provides.
Where it fails: - Verifying a user's physical location — not suitable. An IP address cannot reliably confirm someone is in a specific city or building. - Emergency services and precise local routing — never use IP geolocation for anything where exact location matters. - Identifying a specific individual — an IP address identifies a *network connection*, not a person. Multiple people share IPs (households, offices, CGNAT). This is a frequent misunderstanding in legal contexts. - Mobile user targeting by city — accuracy too low to be meaningful.
This is why reputable IP lookup tools — including this one — display geolocation results with the understanding that the city shown is an approximation, not a confirmed location. The ISP, country, and ASN data are considerably more reliable than the city field.
Why some IPs have no geolocation at all
A small percentage of IP addresses return no location data — or return a generic "unknown" or a location in the middle of the ocean. This happens for specific reasons:
Reserved and private ranges IP addresses in private ranges (192.168.x.x, 10.x.x.x, etc.) are not public IPs and have no geolocation. If you are behind a proxy or VPN that is misconfigured, you may see a private IP appear in a lookup tool.
New IP allocations When a new IP block is allocated, geolocation databases need time to map it. Newly allocated IPs may show no location for days or weeks until the databases update.
Anycast IPs Some IPs are anycast — the same IP address routes to different physical servers depending on the requester's location. Cloudflare's 1.1.1.1 DNS resolver and Google's 8.8.8.8 are anycast addresses. Their geolocation is essentially meaningless: different users looking up the same IP get different results because the IP legitimately responds from different locations depending on routing.
Intentionally obscured allocations Some corporate and government IP blocks are deliberately registered with minimal location data for operational security reasons.
How to check what your IP says about you
The most direct way to see exactly what information your IP address exposes — including the geolocation data, ISP name, ASN, and connection type — is the IP lookup tool at the top of this page.
The tool shows: - Your public IP address - The country, region, and city resolved from that IP (with the accuracy caveats described above) - Your ISP name and ASN (Autonomous System Number) — generally more reliable than the city - Whether your connection is flagged as residential, hosting, VPN, or mobile
The ISP and ASN fields are worth checking even if the city is wrong. They tell you which network your connection appears to come from — useful for confirming a VPN is routing correctly (the ISP shown should be the VPN provider, not your home broadband) or for understanding what type of connection a specific IP represents.
For context on what else gets revealed beyond IP geolocation — including browser-level signals that persist through VPNs — see the browser fingerprinting guide.