What Is GeoIP? How IP Geolocation Works and How Accurate It Is in 2026

GeoIP, or IP geolocation, is the practice of estimating where an IP address is used: which country, region and city, and which network and organization it belongs to. A lookup for one address returns a location record plus network attributes such as the ISP, the autonomous system, the connection type and, on cellular networks, the mobile carrier. Every request that reaches your server already carries a source address, so GeoIP needs no permission prompt, no JavaScript and no GPS.

The short answer to the accuracy question, as of September 2026: country is right more than 99 percent of the time, city is usually right on fixed broadband and usually wrong on mobile. One of the largest public measurement studies of 2026, “Lost in the Prefix”, checked four major databases against 37,302 ground-truth observations in 175 countries and found median errors of 3 to 16 km on fixed lines and 179 to 207 km on mobile networks. The rest of this post explains where those numbers come from, and how to consume a GeoIP result without believing more of it than you should.

A GeoIP database is a list of prefixes, not a map of people

There is no registry that ties an IP address to a street. What a provider actually maintains is a table with one row per prefix and one location per row: 203.0.113.0/24 is used in Lyon, 2001:db8:4000::/40 in Osaka. A lookup is a longest-prefix match against that table, the same operation a router performs, followed by a join against network, company and threat data.

Two things follow. The coordinates you get back are the center of the area the row describes, never the position of a device, so a latitude and longitude field is a city centroid dressed up with six decimals. And the width of the matched row is an accuracy bound. A /29 assigned to one office is precise by construction. A /13 that a carrier spreads across an entire country is not, whatever city is written on the row.

Where the data comes from

Providers assemble location from several independent signals and reconcile them per prefix. None of the signals is authoritative on its own, and each one covers a failure of the others.

Registry records come first. The five regional internet registries, ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC, publish which organization holds each block and the country it was registered in. This anchors country-level data, but a registry country is where the paperwork lives, not necessarily where the routers are. Blocks get leased and transferred across regions, and the record often lags. Our post on IP address information covers what a registration record actually contains.

BGP tells you who operates the prefix right now, and the announcement boundaries show how the operator carves up its space. A Lyon ISP announcing a /22 is a stronger location signal than the registry entry that says the covering /16 belongs to a holding company. Keeping database rows no wider than the announced prefixes is one of the main things that separates a good dataset from a coarse one.

Geofeeds are the only signal written by the party who actually knows. RFC 8805 defines a CSV file, one line per prefix, in which an operator states the country, region and city where each range is used, and RFC 9632 adds a geofeed: attribute on the registry’s inetnum and inet6num objects so consumers can find the file without being told. Adoption is lopsided. At APNIC 62 in Mumbai in September 2026, Sid Mathur’s survey of a sample of Whois-discoverable networks put 75.5 percent of successful geofeed publishers in the RIPE NCC region, 21.6 percent in ARIN’s and 3.0 percent in APNIC’s, per George Michaelson’s write-up published September 24, 2026. Two of the largest public feeds do not come from ISPs at all: Apple’s Private Relay egress list had 285,171 rows when we pulled it on September 25, 2026, 243,357 of them IPv6, and Starlink’s feed.csv about 4,300. We wrote a guide to the format and run a free geofeed checker.

Latency bounds what is physically possible. Light in fiber covers roughly 200 km per millisecond, so a 5 ms round trip from a probe in Frankfurt puts the target within about 500 km of Frankfurt, and since real fiber paths are longer than the great circle, the true bound is tighter. Latency cannot tell Lyon from Grenoble, but it catches a block that the registry places in Miami and the routers place in São Paulo.

Corrections close the loop. Operators and users report mislocated ranges, and a good provider verifies them against the signals above before changing anything. Ipregistry takes data corrections for any address, and network operators get the most durable fix by publishing a geofeed.

Accuracy by connection type, with numbers

The “Lost in the Prefix” paper by Syed Tauhidun Nabi, Jocelyn Bliton, Tijay Chung and Shaddi Hasan, posted to arXiv on May 21, 2026 and summarized by its lead author on the Internet Society’s Pulse blog in August, is the best public yardstick we have. Ground truth came from 10,561 RIPE Atlas probes and 4,872 schools measured by UNICEF’s Giga project in 27 countries. The four databases tested, the free MaxMind GeoLite2 and DB-IP Lite plus the commercial IPinfo and IP2Location DB11, were snapshotted between March 25 and 27, 2026 to match.

Fixed broadband: usually the right city

A cable or fiber subscriber gets a public address from a pool tied to a specific aggregation router, and those pools usually stay within one metro area. A median of 3 to 16 km means half of all answers land within a city’s width of the subscriber, so the city is usually right and occasionally even the neighborhood. This is the case most people have in mind when they quote an accuracy figure, and the only one where the figure holds.

Mobile: the gateway, not the phone

A phone’s packets travel inside a GTP tunnel across the carrier’s backbone to a packet gateway, the P-GW in 4G or the UPF in 5G, and only there do they get a public address, usually from a carrier-grade NAT pool shared by subscribers hundreds of kilometers apart. The database reports the gateway because the internet never sees anything closer. The study found about 70 percent of mobile prefixes span more than 100 km of real user locations, which is the topology faithfully recorded. We took the paper apart in a dedicated post; the short version is to believe the country and the carrier and treat the city as a hint.

Satellite: a point of presence, not a place

Satellite is worse in a specific way: the public address is assigned at the ground-station point of presence, which can sit in a different country from the dish. Starlink publishes its own feed mapping every prefix to a country and city, and geolocation databases largely follow it. That does not make it right. When Geoff Huston at APNIC Labs looked at where Starlink users appeared in September 2025, the feed made Starlink account for 59 percent of Yemen’s estimated users, roughly 6 million people, in a country with an estimated 3.4 million internet users, and showed substantial Starlink traffic in Sudan and Myanmar where the service was not offered. APNIC Labs overrode Starlink’s data for 20 economies. The “Lost in the Prefix” authors excluded satellite observations from their fixed-versus-mobile comparison for the same reason.

Relays and VPNs: the location is someone else’s

iCloud Private Relay is the interesting case, because Apple publishes the location it wants you to see. Its developer guidance states that the relay address “accurately represents the client’s coarse city-level location by default,” and the egress feed carries a country on every row and a region and city on most of them. A database that disagrees with the feed is wrong by definition, and one that agrees is only as precise as the city Apple picked. Commercial VPNs, proxies and Tor exits give you the exit node and nothing else, which is why a location record should always travel with the VPN, proxy, Tor and relay flags that tell you whether to trust it at all.

Country is reliable, city is a hint

The headline numbers hide a distinction that decides whether a GeoIP answer is useful. In the same dataset that produced 200 km mobile errors, fewer than 1 percent of observations per provider landed in the wrong country. The misses cluster in a handful of prefixes rather than spreading randomly. The paper names Fiji observations assigned to the United States, all of them satellite connections, and Turks and Caicos observations assigned to Jamaica: one is a point of presence in another country, the other an address block used across a border its records do not reflect.

City-level failure, defined in the paper as an error above 100 km, follows geography. Europe missed 9 to 20 percent of the time and the Americas 8 to 22 percent, against 43 to 46 percent in Oceania, 53 to 61 percent in Asia and 66 to 72 percent in Africa. The mechanism is prefix width. Between 32 and 40 percent of all database prefixes span more than 100 km of real user locations, the median span of a Global South prefix is 315 to 413 km against 186 to 269 km in the Global North, and for three of the four providers the coarsest prefixes produced the highest errors.

The paper’s recommendation is the one we would give: avoid sub-national claims for mobile and Global South addresses, and treat the size of the matched prefix as a per-observation accuracy bound. Ipregistry returns the announced route with every lookup, so you can apply that rule yourself. A /24 answer and a /12 answer should not feed the same decision with the same confidence.

GeoIP versus GPS and Wi-Fi positioning

People compare these as if they competed. They answer different questions at different costs.

GeoIP wins whenever a decision has to be made before the user does anything: the currency and language of the first page, whether a login is plausible given the account’s history, which regulatory regime applies, and the country column of every log line you will ever analyze. It is also the only one of the three the user cannot fake from inside the device, which is why fraud teams treat an IP-versus-GPS disagreement as a signal and not the other way round (on mobile, remember, a 300 km gap is normal, so compare countries and not cities).

GPS and Wi-Fi positioning win when the product is about the physical position: maps, delivery, ride hailing, anything with a “near me.” There, GeoIP is the fallback for when the prompt is denied, and a decent one, because a city centroid is a better starting map view than nothing.

Calling an API and caching results responsibly

A single REST call returns everything above at once:

curl "https://api.ipregistry.co/8.8.8.8?key=YOUR_API_KEY"

The response bundles location, connection, company, carrier, currency, time zone and security flags. Trimmed to the fields that matter for the trust model in this post:

{
  "carrier": { "mcc": null, "mnc": null, "name": null },
  "connection": { "asn": 15169, "domain": "google.com", "is_anycast": true, "organization": "Google LLC", "route": "8.8.8.0/24", "type": "hosting" },
  "ip": "8.8.8.8",
  "location": { "city": "Mountain View", "country": { "code": "US", "name": "United States" } },
  "security": { "is_proxy": false, "is_relay": false, "is_residential_proxy": false, "is_tor": false, "is_vpn": false },
  "type": "IPv4"
}

Two habits keep this cheap and correct. Cache per address for up to a day, because the underlying data refreshes daily and an address does not move between refreshes; anything longer risks serving a transferred block’s old country. And decide at lookup time how much of the record to believe: a non-null carrier means city is a hint, a true is_relay or is_vpn means the location is the exit’s, a wide connection.route is a warning that the row may be coarse, and a true connection.is_anycast means the address is served from many places at once, so the city is only where the operator registered it. 8.8.8.8 is the textbook case: Mountain View is Google’s headquarters, not the resolver that answered you. For log analytics or batch scoring, the same data ships as downloadable CSV and MMDB datasets so you skip the per-request round trip entirely.

Ipregistry builds its location data from the pipeline described here, registry records, BGP, daily geofeed crawls, latency and verified corrections, and returns it with the carrier, connection and security signals that tell you how far to trust it. You can try it on your own address at ipregistry.co/me or sign up for 20,000 free lookups to get started.