How GeoIP works
GeoIP, also called IP geolocation, estimates the location associated with a public IP address or prefix. A provider matches the address against a versioned database built from registry and routing records, operator-published data, network measurements, corrections, and other licensed or proprietary signals. The answer describes the provider's best estimate for that network range at that time.
A lookup is not a measurement from the device. It normally does not read GPS, Wi-Fi positioning, a street address, or a person's identity. Two providers can return different results because they use different evidence, update cycles, prefix boundaries, and confidence rules.
GeoIP services normally expect a public address. A private or local address does not carry a public deployment location; the public vs private IP guide explains that boundary.
What a GeoIP result means
| Field | Useful interpretation | What it does not prove |
|---|---|---|
| Country | The country a database associates with the network address or prefix. | A person's nationality, residence, current physical location, or the law that applies. |
| Region or city | A more specific estimate that may reflect infrastructure, an access-network gateway, or observed use. | A household, building, device, or exact service location. |
| Coordinates and accuracy radius | An approximate point and uncertainty area supplied by some providers. Interpret the point together with the radius or confidence field. | GPS precision or proof that a user is at the returned coordinates. |
| Postal code and time zone | Derived context that may help choose a default experience when the match is sufficiently reliable. | A deliverable address, billing address, identity, or permanent location. |
| ISP, organization, or ASN | Network context inferred from registration, routing, and provider data. | The individual user, customer account, beneficial owner, or authorization to use the address. |
Country-level data is generally more dependable than city, coordinates, or postal code, but no level should be treated as infallible. Preserve the database name, result date, and uncertainty fields when a decision must be explained later.
Where GeoIP data comes from
| Evidence | What it can contribute | Important limit |
|---|---|---|
| RIR and RDAP records | Resource registration, network name, contacts, country hints, and allocation context. | Registration can be administrative and may not identify where a prefix is deployed or where a user connects. |
| BGP and network topology | Origin ASN, observed routes, upstream relationships, and changes in where a prefix enters the Internet. | A route is control-plane evidence, not a precise user location or proof of resource authority. |
| Operator geofeeds | Prefix-to-country, region, city, and optional postal-code mappings published in a standardized CSV format. | A consumer decides whether and when to use the feed, and the published place remains coarse. |
| Measurements and partner signals | Latency, infrastructure observations, usage patterns, and other evidence that can refine an estimate. | Coverage, methodology, licensing, and update frequency vary by provider. |
| Corrections and feedback | Operator or user reports that help a provider investigate stale or wrong mappings. | A submitted correction is not proof that every database has accepted or distributed it. |
What is a geofeed?
RFC 8805 defines a simple CSV format in which a network operator can map an IP prefix to ISO country, region, city, and postal-code fields. RFC 9632 describes how a consumer can discover and use a feed. More-specific prefix entries can describe a smaller part of an aggregate, and blank location fields can intentionally avoid asserting a value.
A geofeed is operator-published input rather than a universal source of truth. A consumer may verify that the publisher is authorized for the prefix, compare other evidence, reject malformed or implausible entries, and apply its own refresh schedule. RFC 9632 also describes an optional RPKI-signed form; an unsigned feed and an authenticated feed are not the same evidence.
Publishing or updating a feed does not make every GeoIP provider change at once. Record the exact prefix, feed URL, publication time, and expected location, then verify each important provider independently.
How accurate is GeoIP?
Accuracy depends on the requested granularity, address family, prefix history, provider, evidence age, and network design. A country match can be useful while the same record's city is wrong. A coordinate can represent a population center, network facility, or uncertainty area rather than the endpoint itself.
- Mobile networks and CGNAT: many subscribers can leave through a shared gateway far from the handset. The public address identifies the egress mapping, not one subscriber or device.
- VPNs and proxies: a destination usually sees the exit address for traffic that uses the tunnel or proxy. The returned place can describe the exit network rather than the user.
- Cloud and hosting networks: registration, control plane, hardware, workload, and customer can be in different places.
- CDNs and anycast: one address can be served from multiple sites, so a single city may not describe every packet path.
- Newly routed, leased, or transferred prefixes: databases can retain the former location until evidence is reviewed and distributed.
- IPv6 privacy and prefix changes: an interface address can change while the delegated network context remains broader than one device.
Use provider-supplied accuracy radius or confidence information when available. Treat unknown and conflicting answers as normal states that need a fallback, not as reasons to invent precision.
GeoIP vs RDAP, BGP, GPS, and account evidence
| Signal | Question it can help answer | What it cannot establish alone |
|---|---|---|
| GeoIP database | Where does this provider currently estimate the public address or prefix is used? | Exact device position, identity, authorization, or legal residence. |
| RDAP or registry record | Which registry record, resource context, and public contacts apply? | Current routing, deployment location, the end user, or data-plane reachability. |
| BGP and ASN observations | Which origin and paths were visible from particular collectors at a particular time? | Physical location, universal route acceptance, resource rights, or application success. |
| GPS or device location | Where does an authorized device estimate it is, under its sensor and permission model? | The registered holder or network deployment location of its public IP. |
| Account, billing, or delivery evidence | What identity or address information was supplied and verified in that workflow? | The live physical location of every session or the correctness of a GeoIP record. |
The guide on what information an IP address can reveal explains why a timestamp, source port, provider record, and other evidence may be needed before connecting network activity to an account.
Responsible GeoIP use
GeoIP can help choose a default language or region, summarize traffic, select a nearby service endpoint, prioritize a fraud review, or apply a documented policy workflow. Build every use around the consequence of a wrong result.
- Localization: offer a default and let the user correct it. Do not silently lock language, currency, or content to a brittle city estimate.
- Analytics: aggregate where possible, retain the database version or observation date, and respect applicable privacy and retention obligations.
- Routing and delivery: combine GeoIP with health, capacity, latency, and actual request measurements. Location alone does not prove the best or reachable endpoint.
- Fraud and policy review: use GeoIP as one signal. Provide a review and exception path when a decision can deny service, access, payment, or eligibility.
- Security: do not treat a country, ASN, VPN, proxy, or hosting label as proof of malicious intent. Authenticate the user and protect the service directly.
How to check or correct a GeoIP result
- Fix the observation. Record the full public IPv4 or IPv6 address, lookup provider, result, timestamp, database or API version if shown, and the expected country, region, or city.
- Confirm the network path. Check whether the traffic uses a VPN, proxy, mobile gateway, CGNAT, cloud edge, or other egress. Compare IPv4 and IPv6 separately.
- Check prefix and routing context. Review RDAP, the intended prefix boundaries, origin ASN, and current BGP observations. Do not expose a user's full address in a public correction ticket when a prefix is sufficient.
- Review the operator source. If the authorized operator publishes a geofeed, confirm the exact prefix entry, syntax, publication location, and optional authentication evidence.
- Compare important providers. A correction is provider-specific. Submit each provider's documented correction form with bounded evidence and keep the receipt.
- Verify after distribution. Recheck the same address family and provider over time. Record the observed change instead of promising a fixed update date.
GeoIP for leased or transferred IPv4 space
A prefix changing operator, origin ASN, customer, or deployment region can create stale geolocation. Before use, agree who owns RDAP contact accuracy, routing records, geofeed publication, provider corrections, evidence retention, and end-of-term cleanup. Test representative addresses across the providers that matter to the service and preserve dated results.
No lease, transfer, LOA, route announcement, or geofeed guarantees a location result or update time in an external database. If a target region is operationally important, make the accepted providers, granularity, test addresses, exception process, and replacement or rollback conditions explicit. Review strategic IP address management for ongoing registry, routing, geolocation, and reputation coordination, or managed IPv4 leasing when the requirement includes temporary address capacity.
For geolocation coordination, bring the prefix, affected provider, dated result, expected location, authority to act, and recent network changes. Agree who submits corrections and verifies each provider’s response.
GeoIP FAQs
What does GeoIP mean?
GeoIP is a common name for IP geolocation: matching a public IP address or prefix to an approximate network location in a provider's database. It is not an Internet protocol version and does not reveal an exact device location.
Can GeoIP find an exact address?
No. A GeoIP result may contain country, region, city, postal code, coordinates, or an accuracy radius, but it should not be used to identify a household, street address, person, or device. Finer fields usually carry more uncertainty.
Why do GeoIP databases disagree?
Providers use different registry data, routing observations, geofeeds, measurements, partner data, corrections, prefix boundaries, refresh schedules, and confidence rules. Their results are independent estimates rather than synchronized facts.
Does a VPN change GeoIP?
For traffic that uses a VPN, a destination usually looks up the VPN exit address, so the result can describe the exit network. Split tunneling, direct IPv6, DNS, or other bypass paths can expose different network locations and must be tested separately.
What is a GeoIP geofeed?
A geofeed is an operator-published CSV mapping from IP prefixes to coarse location fields defined by RFC 8805. RFC 9632 describes discovery, use, and optional RPKI authentication. Each consumer decides whether and when to accept the data.
How long does a GeoIP correction take?
There is no universal update time. The provider must receive and evaluate evidence, update its data, and distribute the change through its own products and release cycle. Track each provider and verify the result instead of relying on a promised global propagation window.
Can GeoIP prove where a user lives?
No. It estimates network location and can be distorted by gateways, VPNs, proxies, hosting, anycast, stale records, and reassigned prefixes. Residence, identity, eligibility, compliance, and legal decisions require appropriate additional evidence and review.
How should a leased IPv4 prefix be geolocated?
The authorized parties should define the intended prefix location, geofeed and correction owner, supporting routing and registry evidence, providers to test, acceptance criteria, exception handling, and end-of-term cleanup. External providers retain control of their databases, so no result or timing is guaranteed.
