IP geolocation: how it works and why your location is wrong

Every address on the public internet sits in a database row somewhere that says "this block is in Manchester" or "this block is in Ohio". When a website shows your city, blocks a video, or sends you to the wrong language version, it has looked up the address your connection arrived from in one of those databases and taken the row at face value. The row was not measured from your device. It was assembled from registry paperwork, location files your provider may or may not publish, network measurements and corrections, and it describes a block of addresses rather than a house.

That is why the country is nearly always right and the city is a coin toss in some places, and why the location can jump a hundred miles when you switch from Wi-Fi to mobile data. The address a site sees belongs to whoever handed it out: your ISP, your mobile carrier, a VPN provider or Apple's relay service. The database describes where that address pool is used, which is usually near you and sometimes nowhere close. Below: where the data comes from, how far off it typically is, the five situations that produce a wildly wrong answer, and what you can do about each.

Where the location next to an IP comes from

Three kinds of input feed a geolocation database. None involves your device.

The first is registry data. Regional internet registries such as RIPE NCC and ARIN record who holds each block of addresses. Those records carry a country: field, but it is an administrative value: it says where the holder is registered, not where the addresses are deployed. RFC 9632, the 2024 standard on finding geofeed data, says the country: and geoloc: hints in registry objects "tend to be administrative, and not deployment specific" and should be ignored once a proper geofeed exists. A provider registered in London can run a block in Glasgow.

The second is the geofeed, a plain CSV file that a network publishes for its own ranges. RFC 8805, published in August 2020 with authors from Google and Loon, defines the format: one line per prefix, with the fields ip_prefix,alpha2code,region,city,postal_code. The RFC's own example for a RIPE NCC range reads 193.0.24.0/21,NL,NL-ZH,Rotterdam,, meaning the whole /21 is used in Rotterdam, South Holland, Netherlands. The postal-code field is marked deprecated "due to the granularity of this information", and the document says specific postal codes "MUST NOT be published in geofeeds without the express consent of the parties being located". RFC 9632 defines how a vendor finds the file: the registry object for the block carries a geofeed: attribute with a single HTTPS URL (RIPE and APNIC implement it) or a remarks: Geofeed <URL> line. Consumers are told to refresh at least weekly and to "use other sources to cross-validate the data", because a geofeed is the operator's own claim.

The third is everything a vendor measures or is told. MaxMind's accuracy page says country-level location is validated "with traceroutes and proprietary data about where networks are actually in use", and its support article points to a public data correction request form. All of it is combined into one record per block: country, region, city, coordinates for the centre of that place, and an accuracy radius.

Figure: The lookup is a table read. The website never learns anything about you that was not already in the record for the block, and the block may belong to a service you are only passing through.

A worked example

Take the RFC's Rotterdam line and follow it. The holder of 193.0.24.0/21 publishes a geofeed. A vendor fetches the file over HTTPS, checks through the registry that the publisher really holds that block, and writes a record: country NL, region NL-ZH, city Rotterdam, coordinates at the centre of Rotterdam. Any of the 2,048 addresses in that /21 now resolves to Rotterdam on that vendor's data.

A site you visit receives a single address from that block, finds the covering prefix, reads the record, and displays Rotterdam. The record's accuracy radius tells the site how much to trust the city. MaxMind's support article explains the field with the sentence "The actual geolocation of the IP address is likely within the 100km-radius circle shown above" for an address with a 100 km radius. A 5 km radius means the vendor believes the city is right; a 500 km radius means it only believes the country.

Two things follow. If your ISP moves a block from one region to another, the record is wrong until a geofeed or a measurement catches up; RFC 8805's stated motivation is that prefix moves "can degrade services that rely on geolocation" while the algorithms learn. And if the address you are using was never yours in the first place, the record is correct and still useless to you.

How accurate it is, in the vendor's own numbers

The honest answer depends on how fine a location you ask for. MaxMind's accuracy page describes the result as "a set of concentric circles": country-level accuracy "exceeding 99%", state or province "typically ranging from 55% to 80%, depending on the country", and city "typical accuracy rates of 20% to 75%", better in large, densely populated cities. Its support article puts the country figure at 99.8%.

The company also publishes a per-country comparison tool, which is the closest thing to a primary source on city accuracy. Selecting the United Kingdom at a 50 km radius with all network types and both IP versions, the page on 24 October 2026 showed the paid GeoIP City database placing 68% of test addresses within 50 km of their real city, 21% in a city more than 50 km away, and 11% with no city-level data; the free GeoLite City database scored 61%, 30% and 9%. For the United States the same view gave 60%, 32% and 8% for GeoIP City and 56%, 35% and 9% for GeoLite. The page's note says accuracy "is calculated by checking known web user IP address and location pairs" against the databases, and that MaxMind "cannot guarantee any specific future accuracy level".

Screenshot: MaxMind GeoIP accuracy comparison, United Kingdom, 50 km radius, 24 October 2026.

Read those bars the way the vendor intends: for roughly one UK address in three, and two US addresses in five, the city shown is either more than 50 km out or missing. A site that treats the city as fact will be wrong that often, and a site that treats it as a hint with a radius will not.

The five situations that produce a wildly wrong answer

Ordinary error is a neighbouring town. A city in another state or another country almost always comes from one of five causes.

Mobile data. Carriers assign addresses from gateways that serve a wide area, and the same address moves between subscribers quickly. MaxMind's accuracy page says geolocation for mobile devices "typically resolves to a broad region" because an address can be reused by a device "hundreds of kilometers away" within minutes. The database is not wrong about the gateway; the gateway is simply not where you are. More on the difference in residential vs datacenter vs mobile IP addresses.

CGNAT. Fixed-line providers that share one public address among many customers have the same effect on a smaller scale: the record describes where the translator's pool is used, which may be a regional hub rather than your town. If your router's WAN address starts with 100.64 to 100.127, this applies to you; what is CGNAT explains how to tell.

A VPN or proxy. The site sees the server's address, so the record describes the server. MaxMind's support article is direct about it: for an anonymising proxy "we may be able to geolocate the web server being used to run the VPN", but not the end user. A server advertised as one city and recorded as another is fixed by choosing a different server, not by complaining to the vendor.

iCloud Private Relay. Safari users on iCloud+ go through two relays run by different companies, and the site sees a relay address shared among users in the same area. Apple's network preparation page says the relay address "accurately represents the client's coarse city-level location by default" and publishes the egress ranges with their locations as a CSV for database vendors to import. The city is usually right and the provider is not: the lookup shows Apple's relay network, not your ISP.

A default coordinate. When a database knows the country but nothing finer, it has to store something. For years MaxMind's fallback for an address it could only place in the United States was the rounded coordinate 38.0000, -97.0000, which the Boston Globe reported "just happens to be the front yard" of a rented farmhouse near Potwin, Kansas. A Fusion investigation by Kashmir Hill in April 2016 traced five years of police visits, threats and false accusations at the property to that default; the tenants' lawsuit, reported by Courthouse News in August 2016, said more than 600 million addresses had been associated with the farm, and their lawyer said MaxMind had since moved the default into the middle of a lake. Any time a lookup returns a coordinate with a large radius, the point is a placeholder, and nobody lives at it.

Where people get it wrong

The commonest mistake is reading the coordinates as a position. They are the centre of the city or region named in the same record, and the accuracy radius around them is the real answer. A pin with a 100 km circle drawn around it is honest; the pin alone is not.

The second is assuming that two sites disagreeing means one is lying. They bought different data, or the same data on different dates; RFC 8805 lets consumers "treat published feed data as a hint only", and vendors weigh geofeeds against their own measurements differently.

The third is assuming the person described can correct the database. The ISP can add or update a geofeed; the vendor can accept a correction request; the site can buy fresher data. You can only supply evidence and wait.

When it matters

A wrong city is usually cosmetic. It matters when a service uses the record to decide something. Streaming and betting services use country to enforce licensing, and a VPN or relay address that resolves to the wrong country gets blocked outright. Banks and shops compare the city with the one on your account and may flag a transaction. Websites that detect VPNs compare the record's time zone with the one your browser reports; a timezone mismatch is one of the signals, and a mobile address whose gateway sits two time zones away can trip it with no VPN involved. In each case the service is acting on a block-level guess, and knowing that is the first step to arguing with it.

How to check what your address resolves to

1. Open the IP address lookup on the connection you care about. Note the country, city, ISP and ASN it reports, and the accuracy radius if shown.
2. Repeat on a different connection, for example mobile data instead of Wi-Fi, or with the VPN off. If the city changes, the first result described the pool or server, not your line.
3. If the ISP shown is not your provider, you are behind a VPN, proxy, relay or carrier gateway. The IP checker shows whether the address is classed as residential, mobile, hosting or an anonymiser, which explains most jumps on its own.
4. If the provider is right and the city is wrong by a long way, note the distance with the IP distance calculator and send a correction request to the vendor whose result you saw, with the real city and the address block. If you run a network, publish a geofeed for your ranges and register its URL in your registry object as RFC 9632 describes; every major vendor reads them.

The address is the thing being located

Nothing in IP geolocation locates you. It locates an address, from what the address's holder has said about it and what the vendor has observed, and then assumes you are where the address is. On a home broadband line with an attentive ISP that assumption is good to a city. On mobile data, behind a shared translator, through a VPN or a relay, it fails by design, and the database is reporting correctly on an address that was never yours. When the city on screen is wrong, the useful question is not "why is the database broken" but "whose address am I using", and the lookup answers that in one line.