IP Geolocation Test

IP geolocation does not locate you. It locates the block of addresses your provider hands out, using records that say where that block was registered and routed. The panel above resolves your public address against one such database and reports the country, region and city it has on file.

The mechanism is a lookup table. The internet is split into address blocks, from a /24 with 256 addresses up to provider-sized /12 ranges with hundreds of thousands. Registries record who a block belongs to and roughly where, network operators announce which blocks they route, and commercial vendors combine those sources with corrections of their own. Geolocation is that table, queried by your address.

A /24 is small by provider standards, and even that block can be handed out across a whole metropolitan area. A larger block can span a country. When the database has to place a thousand addresses that are used in three cities, it picks one, often the provider’s point of presence where the traffic leaves their backbone. That is the single biggest source of error: the address is not your street, it is the router your traffic reaches first.

Mobile connections are the least precise of all. Carriers route millions of subscribers through the same handful of gateways and frequently keep addresses from another region entirely, so a phone can appear to be hundreds of kilometres from where it is. Home connections behind carrier NAT are similar: one public address stands in for thousands of customers, and the best the database can do is the shared gateway.

The practical rule is simple. Country: usually right. Region: usually close. City: a coin toss that lands in the right area more often than not. A result that looks wrong probably is, and that is a property of the data, not a fault in the reading. Compare it with the address lookup if the two disagree, since they draw on different feeds.

Four sources feed a typical commercial database. The first is registry records, the delegated files and WHOIS entries that regional internet registries publish, which give the owning organisation and its registered country. The second is routing data, the BGP announcements that show which network actually carries a block right now. The third is ground truth collected from apps and SDKs that report a device’s GPS position alongside the address it is using. The fourth is correction over time, as vendors notice their entries drift and patch them.

None of this converges on one canonical answer. Registries list the legal address of the company, not the place the hardware sits. BGP changes daily as routes shift. GPS samples are sparse and skewed towards phones. Vendors weight the mix differently, so for the same address one service can say Lahore while another says Karachi, and both can defend the choice.

That is why the ASN and ISP lookup alongside this tool names the organisation and its autonomous system, which is far more reliable than the city. The network that owns an address is a fact. The coordinates attached to it are inference.

The panel above does something the plain city lookup cannot: it compares the timezone the database gives your IP with the timezone your browser reports, and works out how far the two clocks sit apart in minutes. The browser timezone comes from your operating system. The network timezone comes from the same geolocation record, so this is a comparison of an independent local signal against the database.

When they agree, it means the operating system thinks you are where the network says you are. When they disagree, one of them is stale. The usual causes are a laptop that changed country without the timezone following, a clock set manually and never corrected for daylight saving, or a VPN that moved the address while leaving the local clock on home time. The check compares the actual UTC offset rather than just the zone name, so a spoofed name with an unchanged clock still shows up as a gap.

Read a mismatch as a hint rather than proof. It is one of several signals the timezone and clock test and the proxy and VPN detection test fold together, and on its own it says only that two time sources do not line up.

With a VPN connected, the address every site sees belongs to the exit server, so every field above describes that server’s location rather than yours. Pick a server in Frankfurt and the database will place you in Germany, correctly, because that is where the address is registered. Geolocation is not being fooled; it is answering honestly about a different machine.

What often does not move is your browser’s timezone, still set by your operating system to home time. That leaves the two disagreeing, which is exactly the pattern the clock check flags. It is not a leak of your real address on its own, and it does not mean the VPN has failed. It is simply one more place where a masked connection looks slightly different from an unmasked one.