How IP Geolocation Works Without GPS

Open a shopping site you've never visited and the prices are already in your currency. A news page serves weather for your city. An ad mentions a car dealership ten minutes from your house. Nobody asked permission, nothing beeped, and if you're on a laptop there isn't even a GPS chip to have asked.

The site pulled this off with one piece of information it gets for free the moment you connect: your public IP address. What happens next is part paperwork, part physics, part detective work — and understanding it explains both why websites seem to know where you live and why they sometimes think you live 300 miles away.

Why Does a Website Know I'm in Chicago Before I've Said a Word?

Every device that talks to the internet does it through a public IP address, a numeric label like 57.128.195.96. Your home router gets one from your internet service provider; your phone gets one from your mobile carrier. When your browser requests a page, the server needs that address to send the response back — it's the return address on the envelope, and the server can't not see it. Before it delivers a single byte of content, it can hand that address to a lookup table and get back a country, a region, and often a city. That's IP geolocation: a lookup, not a measurement.

GPS works the opposite way. Your phone listens to timing signals from satellites and computes its own position, accurate to a few meters. The answer lives on the device, and an app or website only gets it if you approve a permission prompt. IP geolocation involves no satellites, no chip, and no consent dialog. It's an inference made about you from the outside, using public records about how the internet is wired. When a browser shows you a little "this site wants to know your location" popup, that's the GPS-style system asking. The IP-based system never has to ask.

A decent analogy is a license plate. A plate tells you the state where a car is registered, which usually matches where the car lives. Usually. Rental fleets get registered in bulk somewhere cheap, people move and keep their old plates, and a car registered in Illinois can spend every night parked in Indiana. The plate is a strong clue with a confidence level attached — not a tracking beacon. Your IP address works exactly the same way.

You can see your own clue right now. Load the lookup on WhatIsMyMyIP's homepage and it will show your public IP, the organization that owns it (almost always your ISP), and the city the internet currently believes you're in. Keep that result in mind, because the rest of this piece explains where each layer of it comes from — starting with a global paper trail.

Where Does the Original Geolocation Data Come From?

IP addresses aren't conjured up by routers or picked by ISPs at random. They're handed down through a strict hierarchy, and every hand-off leaves a public record. That paperwork is the foundation every geolocation database is built on.

At the top sits IANA, the Internet Assigned Numbers Authority, which coordinates the global address pool. IPv4 — the format everyone still thinks of as "an IP address" — is a 32-bit number, which means roughly 4.3 billion possible addresses in total. IANA delegates enormous chunks of that space to five Regional Internet Registries, or RIRs, each responsible for a slice of the planet:

• ARIN — North America
• RIPE NCC — Europe, the Middle East, and parts of Central Asia
• APNIC — Asia and the Pacific
• LACNIC — Latin America and the Caribbean
• AFRINIC — Africa

Each RIR then assigns smaller blocks to organizations in its region — mostly ISPs, plus large companies, universities, and cloud providers. Block sizes are written in CIDR notation, like 203.0.113.0/24. The number after the slash counts how many bits are fixed, so a smaller suffix means a bigger block: a /24 holds 256 addresses, a /20 holds 4,096, and a /16 holds 65,536. An ISP might receive a /19, carve it up by city and neighborhood, and lease individual addresses to customers — usually dynamically, meaning your home IP can change overnight without notice.

Every one of these assignments is recorded in a public registry, and the tool for reading those registries is WHOIS — both a protocol and, loosely, the database it queries. Ask WHOIS about an address and you get back the block it sits in, the legal name of the organization that holds it, a country code, administrative contacts, and registration dates. This is the first and most trustworthy layer of geolocation data, because it isn't measured or guessed. It's contractual. The country in a registry record reflects a legal entity with a physical headquarters, which is why country-level IP geolocation is nearly bulletproof for ordinary connections.

But notice what WHOIS does not tell you. It records where the organization is registered, not where the packets actually flow. A multinational can register a block in Amsterdam and deploy it across forty countries. And because IPv4 ran dry years ago, there's now an active resale market where blocks are bought and transferred across regions — a range born at ARIN in 1993 may be announced from São Paulo today. Registries update their records, but the registry address is still a legal artifact, not a map pin.

There's a second gap: granularity. An ISP covering all of Poland registers a block marked "PL." Nothing in that record says which /24 lands in Warsaw and which lands in Kraków. WHOIS gets you the country and the company. Everything finer has to come from somewhere else.

How BGP Announcements Reveal a Network's True Home

Imagine you run a traceroute and hit a router named core1.frankfurt.de.provider.net. That hostname is a gift. But most routers do not have polite reverse DNS. They show up as anonymous hops with numeric IPs, and a string like 198.51.100.17 tells you nothing about where it sits. To place these invisible hops on a map, geolocation providers turn to the same source routing engineers use to debug the internet: BGP data.

BGP, the Border Gateway Protocol, is the routing protocol that holds the internet together. When a network wants traffic for a block of IP addresses to reach its routers, it announces that block, called a prefix, to its neighboring networks. Those neighbors pass the announcement along, and within minutes the knowledge that this prefix lives behind this network propagates across the globe. Every announcement carries an AS_PATH, a list of autonomous system numbers that functions like a chain of custody, showing exactly which networks a packet would traverse to reach the destination.

Geolocation providers do not guess at this. They subscribe to feeds from route collectors, public projects like RouteViews, RIPE RIS, and PCH, which peer with thousands of networks and log every BGP update they see. When a provider wants to verify where 198.51.100.0/24 actually lives, they query these feeds and ask a series of mechanical questions. Which autonomous system is the origin, the last number in the AS_PATH? Where in the physical world is that AS connected? At which internet exchange points do BGP collectors first see this prefix appear?

The answers are powerful. Suppose the RIR registry says a block is assigned to a company legally registered in Dublin. But BGP collectors only see the prefix announced at DE-CIX in Frankfurt and at the London Internet Exchange. No announcements appear from Dublin, or from any Irish IX. A geolocation provider now has hard evidence that the block is physically in use closer to Frankfurt than to Dublin, regardless of what the paperwork says. Some providers maintain maps of which facilities connect to which IXPs, letting them narrow the location to a specific metro area or even a data center campus.

This happens routinely after mergers and acquisitions. A European hosting provider buys a block originally registered to a North American firm. The RIR records still list a Toronto address. For weeks, some databases place users of that block in Canada. But BGP collectors see the prefix announced only from Amsterdam and Frankfurt. Providers that weight live routing data over static registries correct the location quickly; those that do not serve the wrong language and currency until someone files a manual correction.

But BGP is noisy, and reading it requires skepticism. A small ISP might buy transit from a larger provider and allow that upstream to announce its block everywhere. For hours or days, the prefix looks like it lives inside the upstream's network. Asymmetric routing makes this worse: the path your traffic takes to a collector in London might enter the destination network in London, while traffic from Tokyo enters the same network in Singapore. A geolocation database that trusts only one vantage point will confidently place a user in the wrong hemisphere for half the world's traffic.

There is also the anycast problem, which muddies BGP-based location. A single IP like 8.8.8.8 is announced from dozens of cities simultaneously. BGP collectors see it everywhere, so providers must recognize anycast prefixes and exclude them from triangulation, or they will produce nonsensical results.

The honest trade-off is this: BGP data is invaluable for catching stale RIR assignments and for placing large network blocks within a country or metro area. It's nearly useless for the last mile. It tells you where a network parks its routers, not where a subscriber parks a car. The best geolocation providers use BGP as a correction layer, cross-referencing it against registry data and active probes, rather than treating it as ground truth.

Tracing One Lookup from Start to Finish

It's Tuesday afternoon. A visitor loads your pricing page from Cleveland, Ohio. Their IP — call it 203.0.113.42, an address from a range reserved for documentation examples, standing in for an ordinary residential IP from a major cable provider. Eighty milliseconds later, the geolocation service returns city: Cleveland, region: Ohio, country: US. That result did not come from a single database query. It came from a pipeline of checks, conflicts, and educated guesses. The figures in this walkthrough are illustrative — every provider weights its sources differently — but the sequence is how a commercial lookup typically runs, and you can trace each stage yourself if you know where to look.

First, the service parses the address. Is it a bogon, like 10.0.0.1? Is it a known Tor exit node or a datacenter range? No. It's a public IPv4 address. The system moves to the registry layer. In our example, an ARIN lookup says 203.0.113.0/24 belongs to ExampleNet LLC, registered in Delaware. Country: US. Confidence: high. City: none. Delaware is the corporate headquarters, not the user's bedroom.

Second, the local database query. The block containing this address was remapped three months ago. Why? In this scenario, ExampleNet published a Geofeed file, an RFC 8805 standard CSV that maps IP ranges to latitude and longitude. That file assigned 203.0.113.0/24 to a routing zone covering Cleveland and Akron. Independently, a partner mobile app might report GPS coordinates from users on this same /24 who were physically in Cleveland. The database now carries a city tag with moderate confidence.

Third, active verification. The provider's probe in Chicago pings the address: eleven milliseconds round-trip. From Pittsburgh: four milliseconds. From Detroit: eight milliseconds. Those numbers are this example's, but the logic is real: the latency rings place the target in northern Ohio, not southern. That corroborates Cleveland and rules out Columbus.

Fourth, traceroute analysis. The path crosses a router with reverse DNS reading br2.cleveland1.examplenet.net. That hostname is not definitive, because network engineers can name a router anything. But combined with the Geofeed data and the latency measurements, it shifts probability heavily toward Cleveland.

Fifth, conflict resolution. The same database still carries an old entry from two years prior that labeled this /24 as Columbus, Ohio, based on an automated assumption that the entire parent block was centered near the state capital. The newer Geofeed data and the corroborating probes override the stale entry. Most commercial providers weight recent ISP-published feeds far above historical inferences, precisely because blocks move.

Sixth, confidence scoring. A provider working through evidence like this might report confidence along the lines of: country effectively certain, state in the high nineties, city somewhere in a 70–90% band, postal code little better than a guess. Treat those as illustrative labels, not an industry scale — vendors compute confidence differently, and some don't expose it at all. Why the drop at city level? The block spans multiple Cleveland suburbs. The system knows the user is somewhere in the metro area, but it cannot reliably distinguish Shaker Heights from Lakewood based on network data alone.

Here's the trade-off nobody advertises: steps three through five cost real money. Running a global probe network, buying app partner data, and maintaining traceroute infrastructure requires staff and hardware. A free lookup service often skips the active probing entirely. It stops at the registry and an aging static database, which is why free results frequently show you the ISP's corporate city instead of yours. If you're building a product, decide whether you're willing to pay for the last three steps, or whether a coarse default is good enough.

Why Your ISP Backhauls You to a Different State

You live in Spokane, Washington. You load a store locator and it offers you shipping to Seattle. You've seen this before. The database is not confused. Your ISP simply built a network where all roads lead to Rome, and Rome is a data center in Seattle.

ISPs design regional networks for cost and reliability, not for geographic transparency. Your traffic leaves your house, travels through local neighborhood nodes, then rides a private backbone, often MPLS or dedicated fiber, to a major hub where the provider connects to other networks and the public internet. That hub is called the Point of Presence, and it's where your public IP address is assigned. If you live in eastern Washington, northern Idaho, or even parts of Montana, your ISP may haul every packet to a single large PoP in Seattle before it touches the open internet.

The result: thousands of households across hundreds of miles share IP blocks that geolocate to one city. Network engineers call this backhauling or tromboning, because the traffic travels far out of its way before exiting. Mobile carriers do the same thing at larger scale. A cell tower in rural Oregon may backhaul over microwave or fiber to a packet gateway in Portland. Every subscriber on that tower, and possibly dozens of surrounding towers, gets an IP registered to the Portland metro area. Distance from the gateway matters less than the cost of putting a public internet hand-off in every small town.

The accuracy threshold is roughly this: if you live within about fifty miles of a major city, your IP probably maps correctly to that city because the ISP maintains a local PoP. Beyond a hundred miles, the odds flip. You become an invisible resident of the anchor city. Rural users suffer this most acutely, but even suburban fringes can get sucked into a distant hub if the ISP never built local peering there.

This architecture breaks more than store locators. Streaming services use IP geolocation to enforce regional sports blackouts. If Spokane looks like Seattle, you might be blocked from watching a game that is blacked out in the larger market while you're physically outside the blackout zone. Emergency services that foolishly rely on IP instead of caller location data can route queries to the wrong dispatch center. And any website that calculates sales tax based on IP alone may charge you the rate for the anchor city.

Can you fix it? Not really. Calling your ISP will not make them re-architect a multi-million-dollar backbone so your weather widget shows the right city. Your options are to use GPS, manually enter your location, or accept that the internet sees your network, not your living room. Blame the map if you want, but the map is accurately charting the railroad, not the farmhouse beside it.

IP Geolocation vs. Wi-Fi Positioning and GPS: Which Tool for Which Job

A weather site wants to show the local forecast. It has three ways to find you. Two require asking permission. One does not. That difference alone explains when each method is appropriate, and when relying on the wrong one will make a site look incompetent.

IP geolocation is the silent option. Your public address is visible to every server you touch, so the site can guess your metro area before the page finishes loading. It needs no browser API, no hardware, and works on devices that have no GPS chip, smart TVs, servers, printers. The accuracy is coarse: usually a city, sometimes a region, occasionally the wrong state. Use it for language selection, currency defaults, broad content targeting, and fraud signals like flagging a login from an unusual country. Do not use it to find the nearest pharmacy. You will send someone to the wrong neighborhood.

The Browser Geolocation API is the precise option. When a site calls navigator.geolocation, the browser asks the operating system, which may fuse GPS satellite data, Wi-Fi access point scans, and cell tower IDs. Accuracy can be within meters. The catch: a permission dialog appears, and many users click Block. It also fails on devices without location hardware or in browsers where the feature is disabled. Use this only when you genuinely need the person, not the network: turn-by-turn navigation, finding the closest physical store branch, or geofencing a building.

Between those two sits Wi-Fi positioning, which users rarely see directly. Your phone or laptop scans nearby router MAC addresses and queries a database run by Google, Apple, or Mozilla to match those BSSIDs against surveyed coordinates. It works indoors where GPS signals die. But websites cannot do this themselves; the device does it silently and hands coordinates to the browser only if you grant permission. It's an ingredient in Browser Geolocation, not a separate web API you can call from a server.

Cell tower positioning is similar: your carrier knows which tower you're attached to, but websites do not, unless a mobile app has explicit access to telephony APIs. Some carriers do offer APIs to enterprise customers, but they are expensive, slow, and raise privacy compliance questions that IP geolocation simply does not have. For standard web browsing, cell data is irrelevant.

Method	Accuracy	Requires Permission	Works on Any Device	Best Used For
IP Geolocation	Metro area	No	Yes	Defaults, language, fraud screening
Browser Geolocation	Meters to tens of meters	Yes	Most modern devices	Navigation, precise store finding
Wi-Fi Positioning	Building-level	Implicit via OS	Laptops, phones	Indoor location via device OS

The rule I follow is simple: use IP geolocation to set intelligent defaults the instant the page loads. If the user wants precision, offer a find near me button that triggers the Browser Geolocation API. Never ask for GPS coordinates just to guess a language. That wastes trust. And never rely on IP alone for legal jurisdiction, tax calculation, or emergency routing. The internet's plumbing was not built for that kind of precision.

What It Actually Costs to Map the Internet

MaxMind publishes a free GeoLite2 database. The download is a few megabytes and the license asks only for attribution. That generosity masks an expensive operation. Understanding where the money goes explains why free data lags behind reality, and why serious applications eventually pay.

Building a geolocation database requires a probe network: hundreds or thousands of servers worldwide, constantly pinging addresses and recording traceroutes. Each server costs money to host, and the bandwidth to flood the internet with probes is not trivial. Providers also buy data from partner mobile apps and websites, essentially purchasing crowdsourced GPS-to-IP correlations. Those contracts are confidential, but they are not free. Then there are human analysts who resolve conflicts when three sources disagree about whether a /24 lives in Austin or San Antonio, and legal teams who handle takedown requests when privacy advocates complain about collection practices.

Free tiers, like GeoLite2, are loss leaders. They are updated less frequently than commercial feeds and omit fields like connection type, ISP name, and autonomous system details. For a hobby site setting a default language, that's fine. For a business calculating sales tax or enforcing a geographic license, stale data is risky. IP blocks move, especially in cloud environments where a provider can reassign a range to a different region overnight.

Paid implementations come in two flavors. A real-time API gives you the freshest data, sometimes updated daily, but you pay per query or for a monthly quota. At scale, say a busy SaaS platform performing millions of lookups, those fractions of a cent add up to a real line item. Alternatively, you can license a downloadable database in MaxMind's MMDB format and host it yourself. Queries become local and lightning-fast, but you must engineer a pipeline to download, verify checksums, and hot-swap the file without restarting your application. That's engineering time, which is also money. And the database consumes RAM. A full commercial MMDB can occupy several hundred megabytes of memory, which you must budget for in a lean containerized service.

Tier	Update Frequency	Typical Data Fields	Accuracy	Best For
Free / GeoLite2	Biweekly or slower	Country, city, coordinates	Country high; city variable	Hobby projects, coarse localization
Pro API	Daily	ISP, ASN, connection type, proxy flag	City-level, refreshed often	SaaS apps, e-commerce, ad targeting
Enterprise DB	Continuous or on-demand	Full fields + risk scores, custom feeds	Postal code attempt	Fraud prevention, compliance, streaming rights

My recommendation is straightforward. Start with the free MMDB for rate limiting and language selection. The moment you're making business decisions that cost money, shipping, tax, content licensing, upgrade to a paid tier. Stale geolocation data is more expensive than a subscription. One wrong tax jurisdiction or one fraudulent transaction allowed through because the IP database was six months old will pay for a year of good data.

Why Starlink, Cloud PCs, and 5G Home Internet Break Every Map

You're sitting on a porch in rural Maine. The IP lookup says New York City. You did not move. Your internet did.

Starlink does not hand out IPs that map neatly to your county. Your dish beams traffic to a low-earth orbit satellite, which dumps it at a ground station. That ground station owns the public IP block. If the nearest active ground station with capacity is near Albany, every geolocation database will place you in upstate New York. Worse, as satellite beams shift and network load changes, your apparent location can drift between ground stations. The IP is not wrong. The assumption that an IP stays near its user is.

Cloud PCs and Desktop-as-a-Service create a different mirage. Services like Shadow, Paperspace, or enterprise VDI host a full Windows desktop in a data center. You log in from your couch in Denver and browse from an IP in Dallas. The geolocation service is not making a mistake. It's correctly locating the machine you're using. If you're trying to access a Denver-only news stream through a cloud PC, you will fail, because the internet sees the data center, not the couch.

5G fixed wireless adds another wrinkle. Providers like T-Mobile Home Internet or Verizon 5G Home use Carrier-Grade NAT and assign addresses from large pools anchored to regional packet cores. A subscriber in Fort Worth might share an exit IP with subscribers in Oklahoma City or Little Rock, because all three cities' traffic converges on the same core gateway before it ever touches the public internet. CGNAT means the carrier never gives your home a unique public address at all: your gateway receives a private address inside the carrier's network, and hundreds or thousands of households are translated through one shared public IP at the core. A geolocation database can only place that core, and the core legitimately serves a multi-state region. Reboot your gateway and you may pull an address from a pool anchored to a different core entirely — which is why some fixed-wireless customers watch their apparent city hop around week to week without going anywhere.

What should you do with this? As a user, treat metro-level errors on satellite, cloud, and fixed-wireless connections as normal behavior, not a malfunction to troubleshoot. When a site gets your location wrong and it actually matters — a store pickup, a local news stream, a delivery estimate — look for the manual location setting rather than fighting the IP. It takes ten seconds and it sticks. A quick lookup on a tool like WhatIsMyMyIP will show you what the internet currently believes about your connection, which is useful context before you spend an hour debugging a problem that lives in your provider's architecture.

As a product team, the rule is harsher: never let an IP lookup make a final decision on these connections. Use it to pre-fill a sensible default, then offer a one-click "use my precise location" through the browser's geolocation API for anyone who needs better, and always let users override and save a manual choice. If the IP says Dallas but the customer's saved address says Denver, trust Denver. The cost of asking once is trivial. The cost of confidently serving the wrong region to a customer who can't correct it is a support ticket you deserve.

Sources

• Internet Assigned Numbers Authority (IANA) — The claim that IANA is at the top of the IP address allocation hierarchy, managing the global pools of IPv4 and IPv6 addresses.
• ARIN (American Registry for Internet Numbers) — The claim that Regional Internet Registries (RIRs) like ARIN receive IP blocks from IANA and assign them to organizations like ISPs within their geographic region.
• RIPE NCC (Réseaux IP Européens Network Coordination Centre) — The claim that RIRs maintain a public database (like the RIPE Database) where information about IP address and ASN assignments (WHOIS data) can be looked up.
• IETF (Internet Engineering Task Force) RFC 8805 — The claim that a standardized format called 'Geofeed' exists for network operators to self-publish their IP geolocation information.
• CAIDA (Center for Applied Internet Data Analysis) — The claim that academic and research organizations perform large-scale internet measurements using tools like traceroute to map network topology, which can inform and validate geolocation data.