Quick answer
IP geolocation does not read a location out of an IP address. It ties an address or prefix to the geographic area where that network is believed to be in use. Providers build that estimate from network registration, BGP and ASN context, operator-published geofeeds, active measurements, infrastructure naming, historical observations, and correction data.
Country mapping is the strongest layer. City mapping varies far more with network type, market, vendor, and data freshness. A public IP lookup is not a street-address lookup, and it is not GPS.
If your immediate problem is an IP lookup showing the wrong city, read Why Is My IP Address Showing the Wrong Location? first. This guide goes one layer deeper: how IP geolocation is built, what each field means, and how to judge the result.
Related tool: IP Lookup — it shows the public address, covering prefix, origin ASN, routing context, and the geolocation estimate as separate layers.
01 / Model
What IP geolocation actually does
An IPv4 or IPv6 address carries no latitude, longitude, city code, or country code. The addressing protocol gives routers a destination. The location an IP lookup shows you comes from a separate dataset.
A geolocation provider keeps mappings between address ranges and geographic attributes. In prefix-based databases, an address resolves to the matching network record in that product; the indexing and prefix granularity are vendor-specific, and the granularity shifts as the evidence improves. The record carries fields such as country, subdivision, city, coordinates, time zone, and, depending on the product, an accuracy radius or confidence value.
The lookup does not reach out to the device behind the IP. The answer already exists in the provider's dataset. What matters is how that dataset was built, and how recently the record covering your address was updated.
Routing answers a different question from geolocation. Routing: which network originates this prefix, and how is it reachable? Geolocation: where is this address range believed to be in use? The two overlap in practice, but they are not the same question.
| Field | Network fact or estimate? | What it tells you |
|---|---|---|
| Public IP | Observed network fact | The source address the service sees, after any NAT, proxy, or VPN exit. |
| Prefix / route | Observed routing fact | The routed block that covers the address. |
| Origin ASN | Observed routing fact | The autonomous system that originates the prefix in BGP. |
| Registered country | Administrative record | The country on the registration or allocation record. Not proof of user location. |
| Geolocated country / region / city | Derived estimate | The provider's best location mapping for the address or prefix. |
| Coordinates + radius | Derived estimate | A center point plus an uncertainty area. Not a device fix. |
02 / Inputs
Where IP location data comes from
Commercial databases do not publish the full detail of their pipelines, and the source mix is part of the product. Picture the system as a set of signal families feeding an inference step rather than a single authoritative database.
| Signal family | Useful for | What it does not prove |
|---|---|---|
| RIR / RDAP / WHOIS registration | Ownership, allocation context, registered country, contact and network records. | Where an end user physically sits. |
| ASN and BGP data | Origin network, routed prefix, operator footprint, routing changes. | A subscriber's city or street address. |
| Operator geofeeds | Prefix-level country, region, and city hints published by the operator. | That every subscriber sits at the listed point. |
| Active measurement | Constraining infrastructure location with RTT, topology, and distributed probes. | Straight-line distance to a residential user. |
| Reverse DNS / infrastructure naming | Location hints in router and POP hostnames. | That a hostname label is current or accurate. |
| Historical observations and corrections | Spotting stable use patterns and repairing stale records. | That an old mapping still holds after a transfer or re-pool. |
| Proprietary location datasets | Extra ground-truth signals a given vendor holds. | A shared methodology across providers. |
One note on latency. Light travels through fiber at roughly 200,000 km/s, so in pure propagation terms 1 ms of round-trip time is about 100 km of one-way fiber. Real paths run longer than the straight line and add serialization, queuing, switching, and routing delay, so RTT sets an upper bound on distance rather than measuring it. RIPE IPmap uses RIPE Atlas measurements as one of several engines for locating Internet infrastructure.
- RIR / RDAP registration
- ASN + BGP context
- Operator geofeed
- Latency / topology measurements
- Reverse DNS / infrastructure hints
- Historical observations / corrections
03 / Registry
RIR data is not geolocation
A persistent mistake is reading the country field in RDAP or WHOIS as the physical location of the addresses. That field is administrative context. It reflects the organization that received the allocation, the legal entity that manages it, or a registry object that predates the current deployment.
This breaks in predictable ways. Multinational networks hold address space in one jurisdiction and use it in several. IPv4 transfers and leasing move ranges between operators. Cloud and hosting providers redeploy capacity. Legacy allocations carry historical records that say more about ownership than about current traffic.
Treat RIR data as evidence about the network, not proof about the user. A sound geolocation implementation keeps the registered country separate from the geolocated country instead of collapsing them into one field.
04 / Routing
ASN and BGP narrow the network, not the city
The origin ASN tells you which autonomous system advertises the prefix. On a regional access network that narrows the country, and sometimes the operational region. It does not identify the subscriber's city.
The limit shows up on large backbones, cloud networks, CDNs, and mobile carriers. One ASN originates prefixes used across many countries. A prefix moves between facilities without changing the operator's identity. BGP tells you who advertises reachability. It does not encode the physical rack, the gateway, or the household.
Anycast exposes the limitation clearly. The same prefix is announced from many sites at once, and different users reach different instances depending on routing. For an anycast service, “where is this IP?” is an incomplete question until you also name the observer and the path their traffic took.
If the prefix and origin ASN are exactly what you expect but the city is wrong, stop troubleshooting BGP. Look at the geolocation mapping, the prefix history, the geofeed, or the network's egress design.
05 / Geofeeds
ISP geofeeds: RFC 8805 and RFC 9632
RFC 8805 defines a simple CSV format for publishing coarse location data per IP prefix. It makes prefix-level corrections machine-readable, so an operator publishes once instead of filing the same correction with every data vendor by hand.
# RFC 8805-style examples using documentation prefixes 192.0.2.0/24,US,US-CA,San Jose, 198.51.100.0/24,DE,DE-BW,Stuttgart, 2001:db8:4000::/36,AU,AU-NSW,Sydney,
RFC 9632 defines geofeed discovery through RPSL inetnum / inet6num objects and an optional RPKI-based authentication method. A consumer can locate the feed from registry data instead of an out-of-band URL.
A geofeed is still operator-published data. It is an operator-published location assertion for the prefix, not a measurement from every subscriber. Consumers weigh it against other evidence and their own trust policy. If you run a network with a persistent misgeolocation, a current geofeed is one of the highest-leverage fixes you have.
06 / Inference
How vendors turn network signals into country, region, and city
No public, universal scoring formula exists for IP geolocation. Providers build proprietary pipelines, draw different prefix boundaries, ingest sources on different schedules, and set different confidence thresholds. That is why two reputable databases disagree without either one being broken.
Conceptually, stronger agreement between independent signals supports a more specific mapping. Each vendor decides how those signals are weighted and when to suppress city-level output. When the signals conflict, the defensible result is broader: country instead of city, a wider radius, a lower confidence score, or no city at all.
| Output level | What the field really represents | How to use it |
|---|---|---|
| Country | The national market where the prefix is believed to be in use. | Strongest default layer. Still verify it for high-impact decisions. |
| Region / state / province | The administrative subdivision tied to the prefix's mapped use. | Useful for regional context. Weaker on large or frequently re-pooled networks. |
| City | A city or metro label tied to the network mapping. | Approximate. Do not read it as the subscriber's physical city. |
| Coordinates | A representative center point for the estimated area. | Do not render it as a precise device pin. |
| Accuracy radius / confidence | The vendor's uncertainty around the result, where the product provides it. | Carry it into the decision. Do not drop it from the UI. |
07 / Disagreement
Why MaxMind, IP2Location, IPinfo, DB-IP, and other databases disagree
Different answers are expected. There is no authoritative city registry for IP addresses, and each provider makes an independent inference from partly overlapping evidence.
| Divergence factor | What changes |
|---|---|
| Source mix | One provider leans on operator data; another leans on its own observations or measurement coverage. |
| Prefix granularity | One provider splits a large routed block into several location mappings; another keeps one broad mapping. |
| Update cadence | Transfers, re-pooling, and network changes land in each dataset at different times. |
| Confidence policy | One provider drops the city when evidence is weak; another returns a city with a wide radius. |
| Treatment of mobile / hosting / privacy networks | Providers classify and locate this infrastructure differently, especially when the visible IP sits far from the user. |
Disagreement is itself information. If several providers independently land on the same country and metro, confidence goes up. If they scatter across cities or regions, treat the location as unstable and go look at the prefix. Do not average the coordinates into a midpoint that no dataset actually reported.
08 / Accuracy
How accurate is IP geolocation, really?
No single accuracy percentage survives a change of vendor, country, network type, IP family, and distance threshold. “95% accurate” means nothing until you ask: accurate to what — country, state, city, or 50 km? Broadband or cellular? IPv4 or IPv6? Which market? Which database release?
MaxMind, for example, reports country-level accuracy above 99% overall and publishes a country-by-country comparison for its city data. That comparison shows how wide the spread is even in high-value markets. At a 50 km threshold, the published GeoIP City figures are 61% for the United States, 74% for Canada, 64% for Australia, 67% for the United Kingdom, 70% for Germany, and 49% for France. These numbers are vendor-specific, they change between releases, and they are not a cross-vendor benchmark.
| Market | MaxMind GeoIP City: within 50 km* | Why this matters |
|---|---|---|
| United States | 61% | A large market, but city precision is not guaranteed. |
| Canada | 74% | Higher in this snapshot, still not a device-level fix. |
| Australia | 64% | Wide geography and network design both pull on the result. |
| United Kingdom | 67% | Country accuracy and city accuracy are separate numbers. |
| Germany | 70% | A city result still needs its radius to be read correctly. |
| France | 49% | One global city-accuracy figure would hide this spread. |
*Vendor-reported MaxMind GeoIP City comparison, checked September 2026, combined default view. Use the vendor's live tool for current numbers and for filtering by cellular/broadband and IPv4/IPv6.
IP2Location runs its own country-by-country validation with a different methodology and a 50-mile threshold. That is the reason vendor headline numbers do not compare cleanly: they are not measured on a shared test set.
For production systems, benchmark the vendors on ground truth you control. Separate broadband, cellular, hosting, VPN/proxy, and IPv4/IPv6. Measure the distance threshold that matters to your product. A city name by itself is not a useful test metric.
09 / Radius
Accuracy radius: the field most interfaces throw away
Some geolocation products return latitude and longitude with an accuracy radius attached. The coordinates are the center of an area; the radius is the uncertainty around that center. MaxMind explicitly tells users not to assume the address sits at or near the center point.
Database output City: Denver Latitude / longitude: center point Accuracy radius: 50 km Correct reading: "The mapped IP is likely somewhere in the surrounding area." Wrong reading: "The user is at this map pin."
Vendors do not define radius or confidence the same way, so read the provider's documentation. Keep the uncertainty field with the result. An interface that shows the map pin but drops the radius is claiming more certainty than the data supports.
10 / Mobile
Mobile networks, CGNAT, and centralized egress
Mobile networks separate the handset's physical position from the public address a website sees. In LTE, user traffic is anchored through the packet core and leaves toward external networks through a P-GW. In 5G Core, user-plane traffic reaches the data network through one or more UPFs. Operators place those functions centrally or spread them out, depending on the network design.
CGNAT is common on mobile IPv4 networks, where many subscriber sessions share public address pools. The public IPv4 address then describes the carrier's translation and egress architecture, not one handset. Native IPv6 takes IPv4 CGNAT out of the IPv6 path, but the geolocation still follows the prefix assignment and the carrier's deployment.
- LTE P-GW / 5G UPF
- IPv4 CGNAT where used
Roaming adds another variable. Some traffic is home-routed; other deployments use local breakout. The visible country or region depends on the roaming and egress design, not just on where the phone is.
11 / IPv6
IPv4 vs IPv6 geolocation
IPv6 changes the address architecture, not what geolocation is doing. A native IPv6 path has no IPv4 CGNAT, which removes one source of distortion, and customer prefix delegation gives vendors a stable unit to map, as long as the ISP's assignment policy is stable.
The hard part is coverage and granularity. A provider needs enough evidence to map large IPv6 ranges without over-aggregating them, and enough restraint not to treat every /64 as an independent city-level location. Delegation sizes vary between networks. No single prefix length means “one customer” or “one location.”
IPv6 privacy addresses do not defeat prefix-level geolocation. They rotate the interface identifier inside the delegated prefix, while the geolocation database works at a much broader range. The mapping survives normal privacy-address rotation.
IPv6 removes IPv4 CGNAT from the IPv6 path, but accuracy still depends on prefix allocation, the operator's allocation design, provider coverage, and how fresh the mapping is.
12 / Exits
VPNs, proxies, privacy relays, and “virtual” locations
A VPN does not switch off IP geolocation. It changes which address the destination sees. The database then geolocates the VPN exit, not the user's access-network address.
The same model covers proxies, corporate full-tunnel VPNs, and privacy relays. Apple documents that iCloud Private Relay swaps the original IP for a relay address and is built to preserve a coarse location by default. The visible edge moves; the user's original public address is no longer what gets geolocated for that connection.
Some commercial services advertise “virtual locations,” where the location presented to websites differs from the rack that actually hosts the server. That is a product and routing choice. It is not evidence that latency can pinpoint a building. Measurements are good for plausibility checks; Internet paths are not straight lines.
13 / Limits
What IP geolocation cannot tell you
A good IP lookup is useful precisely because it stays inside the limits of the data.
- It does not give a reliable street or household address. Public geolocation products are built for approximate network location, not residential identification.
- It does not identify a person. One public address can front a household, an office, a hotspot, a VPN exit, a hosting platform, or many subscribers behind CGNAT.
- It does not prove where a user was at a given time. That needs the access provider's session records; under CGNAT it also needs the translated source port or port block, the protocol, and a timestamp. Access to those records follows the law and process of the relevant jurisdiction.
- It does not follow a device between networks. Change the access network or the relay, and the visible IP context changes with it.
- It does not turn registration data into physical evidence. Registered country, origin ASN, and geolocated city answer three different questions.
Special-purpose and non-public ranges need separate handling. RFC 1918 private space, loopback, documentation prefixes, and RFC 6598 Shared Address Space (100.64.0.0/10) are not globally routed subscriber identities, and a public geolocation service should not present them as ordinary Internet locations.
14 / Product
How a serious IP lookup should present location data
A frequent implementation error is collapsing network facts and location estimates into one authoritative-looking card. Keep what was observed apart from what was inferred.
| Show as network facts | Show as location intelligence |
|---|---|
| Public IP address | Geolocated country / region / city |
| IP version | Coordinates, if the provider returns them |
| Covering prefix | Accuracy radius / confidence |
| Origin ASN and organization | Registered-country vs geolocated-country distinction |
| Routing / RPKI context where available | Provider or source context where appropriate |
IPRevealed follows that split: address, prefix, ASN, and routing context are network facts; geography is a separate location-intelligence layer. A city label should never stand in for a GPS reading.
When results disagree, do not average cities. Show the disagreement, or lower the precision you claim. A dataset that conflicts with the others is telling you something about the prefix: mobile use, a recent transfer, broad pooling, infrastructure egress, stale data, or not enough evidence.
15 / Workflow
How to read an IP geolocation result like a network engineer
When a location matters, read the result in this order.
| Step | Check | What a mismatch means |
|---|---|---|
| 1 | Public IP and IP version | Confirm you are geolocating the address the destination actually sees. |
| 2 | Prefix and origin ASN | Confirm the address belongs to the expected network and the route looks normal. |
| 3 | Access / exit type | Mobile, CGNAT, VPN, proxy, corporate tunnel, satellite, or cloud each change what the visible IP represents. |
| 4 | Registered vs geolocated country | A gap here is consistent with a deployment that sits away from the registration record. |
| 5 | City plus radius / confidence | Judge the city at the precision the provider actually claims for it. |
| 6 | Second database | Agreement raises confidence; disagreement is a reason to lower precision, not to average. |
| 7 | Geofeed / prefix history (if you run the network) | Stale or missing operator data is fixable at the source. |
For a live test, run the address through IPRevealed IP Lookup. If the specific problem is a wrong city, use Why Is My IP Address Showing the Wrong Location? instead of chasing it as a routing failure.
16 / FAQ
Common questions
Can someone find my exact home address from my IP?
Not from ordinary public IP geolocation. Providers such as MaxMind state plainly that their data is not precise enough to identify a household or a street address. Tying a subscriber to an IP at a specific time depends on records held by the access provider, not a public city database.
Why does my IP show the wrong city?
The usual causes are in the network or the dataset: regional ISP pools, mobile-core egress, CGNAT, VPN or proxy exits, a transferred or re-pooled prefix, stale vendor data, or a city assigned from weak evidence. Why Is My IP Address Showing the Wrong Location? walks through that diagnosis step by step.
Which IP geolocation database is the most accurate?
No provider wins across every market and network type. Test vendors against ground truth that matches your use case, and keep country, region, and distance-based city metrics separate. A fixed-broadband benchmark in the United States tells you nothing about the same database on mobile IPv6 in Australia.
Does IP geolocation work for IPv6?
Yes. The same principle applies: map a prefix to an estimated geographic area. Native IPv6 avoids IPv4 CGNAT on the IPv6 path, but accuracy still depends on prefix allocation, provider coverage, and data freshness.
Does a VPN hide my location?
It hides the access-network IP from the destination and puts the VPN exit IP in its place, so IP geolocation then describes the exit. Other location signals, such as device permissions, account data, Wi-Fi positioning, and application telemetry, are separate systems, and a VPN does not touch them.
Is IP geolocation reliable enough for fraud or access control?
It works as one signal, especially at country level. It should not be the only proof of where a person is. High-impact decisions need the provider confidence or radius, the network-type context, and independent signals sized to the risk.
Is IP geolocation legally reliable evidence?
Treat it as technical context, not standalone proof that a person was somewhere. Evidentiary rules and access to subscriber records vary by jurisdiction. If a decision turns on location, get qualified legal guidance and corroborating technical records.
17 / References
Technical references
- RFC 6890 / 8190
- IANA IPv4/IPv6 Special-Purpose Address Registries
- IP2Location
- IP geolocation data accuracy methodology
- 3GPP
- TS 23.401 (LTE/EPC) and TS 23.501 (5G System)