IP Geolocation Databases & Checkers

An IP geolocation database maps IP addresses to estimated locations. An IP checker displays a result from a database or another data source. Two checkers can place the same proxy IP in different countries because they use different suppliers, products or versions of the data. Understanding where each answer comes from helps you decide whether a proxy meets your location requirements.

Within Proxy Geolocation & Targeting, databases explain how an address acquires a country or city label. For a proxy buyer, the useful questions are who supplied that label, what it describes and whether the website you need to use accepts the same location.

How a database assigns a location

An IP address does not contain a country code or geographic coordinates. A database associates an address or a range of addresses with location information. The numbers in the address alone cannot tell you where a proxy server stands.

Data suppliers build those associations from several kinds of evidence. Registration records describe internet number resources and the organizations responsible for them. Network operators can provide information about where they use their addresses. A geofeed is a published file that maps IP ranges to locations, allowing operators to communicate changes in a machine-readable form.

Publishing a geofeed does not force every database to accept it. The organization receiving the file decides how to verify its contents and resolve disagreements with other evidence. Confirming that an operator controls an address range establishes who can speak for that range; the stated location still needs evaluation.

Network measurements provide another source of evidence. IPinfo, for example, describes using probes in different locations to estimate where addresses are used, with registration records, geofeeds and submitted corrections as additional inputs. This is the supplier's description of its method, not a measured ranking against other databases. A single ping from your own computer does not reproduce that process: its delay also depends on the route and network conditions.

Transaction data can also inform location records. MaxMind states that it uses some information submitted through its minFraud service to improve its IP data products. This can include billing location considered alongside other information. Its geolocation records therefore draw on evidence beyond the country written in a registration record. This does not make minFraud an exact locator of a person or make a billing address conclusive evidence on its own.

Each supplier decides how to combine evidence, how much detail to return and when a record should change. Agreement between databases is useful, but there is no single worldwide geolocation record that every checker must reproduce.

Why the registry and a checker can disagree

Regional internet registries such as RIPE NCC and ARIN maintain registration information for IP resources. Their role differs from that of a commercial geolocation database. RIPE's documentation explicitly warns that the country field in an address record can refer to different things, including an organization's headquarters or a server location. It is not a reliable universal map of where addresses are used.

This distinction matters when a datacenter proxy service uses leased address space. A block may change operator, be divided into smaller ranges or be put to use in a new location. Updated registration information and updated commercial geolocation records are separate changes. Editing a country field also does not move the server that sends the traffic.

Consider a proxy sold as Japanese. Its provider points to a registration record showing Japan, while the customer's checker reports another country using MaxMind data. The registration record confirms what is recorded there. It does not establish what MaxMind must report. MaxMind's correction policy specifically allows its location assessment to differ from the WHOIS country.

The buyer's question remains practical: does the supplied address work as the Japanese exit they were promised? A reference to the registry cannot answer that question on its own. If a particular database is the agreed criterion, the address needs to be checked against that database. If the requirement is successful use on a particular website, a separate database result is only part of the evidence.

An ISP name in a report does not settle the location either. It identifies a network relationship according to that data product. A network label, a registration country and an estimated exit location describe different properties.

Which companies supply the data

MaxMind, IPinfo, IP2Location and DB-IP publish IP data products. Their names may appear on their own lookup pages or as the credited source on someone else's checker. The product matters as well as the company name.

Free datasets can be useful for an initial check. They should be identified accurately when a result is used to challenge a supplier or compare databases. A paid product is not automatically correct for every address either: deciding which source locates an IP more accurately requires evidence about where that address is actually used.

Even a database file format does not identify its author. Files ending in .mmdb can contain data from suppliers other than MaxMind. The format tells software how to read the file; the dataset name tells you whose information is inside it.

Why several checkers may repeat one answer

A checker can query a data supplier's API, search a downloaded copy of its database or combine several sources in one report. An aggregator can show results from different suppliers side by side. For example, IPLocation identifies third-party providers in its comparison results.

These arrangements make data easier to access, but they also create a trap: the number of websites showing a country is not necessarily the number of separate assessments supporting it.

Suppose you check one fixed IP on three websites. In this illustrative example, Checker A and Checker B both display Japan from the same dataset. Checker C displays Germany from another dataset. There are three interfaces but only two data sources in that comparison. Counting the first two results as separate votes overstates the evidence for Japan.

Look for the named supplier, product and release date where available. When a report does not disclose its source, record it as unknown. Matching answers or a similar page design are not enough to prove that two checkers use the same database. Different suppliers can also share some inputs, so separate company names do not guarantee completely separate evidence.

A single report may mix sources too. Its country, ISP name, proxy flag and browser time zone need not come from the same place. Read the labels around the result you are investigating. A browser test can add useful information, but its overall score is not a replacement for the IP's country field.

For a fair comparison, enter the same recorded exit IP into each lookup. If you simply open several “What is my IP?” pages through a rotating service, each page may receive a different address. You would then be comparing different exits rather than conflicting records for one IP. The proxy gateway's address may also differ from the exit address seen by the destination.

How to read the result

A lookup page can put several location-related fields next to one another. Their meanings determine what the result can support.

MaxMind, for example, can report a larger metropolitan area for an address used in a neighboring town. A buyer needing a specific municipality should establish whether that label meets the task's requirements. Agreement on the country does not settle a city-level requirement.

Coordinates also deserve careful reading. In MaxMind products, an accuracy radius describes an area in which the IP is likely to be located. The map's center should not be treated as the proxy server's street address. Other products have their own field definitions, so an unlabeled point should not be assigned a precision the supplier has not stated.

A missing city can reflect limited detail in the purchased product or uncertainty about the address. Some networks cover an area too broad for a useful city estimate. Adding more decimal places to coordinates would not resolve that uncertainty.

An IP time zone is a database value associated with the IP's estimated location. A browser time zone comes from the user's environment. A page showing both is comparing two kinds of information; changing a computer's time zone does not rewrite the IP database.

Why updates reach checkers at different times

There are several steps between a change in a network and a changed result on a lookup page. The data supplier must obtain and assess new information, update its records, and make the result available. A service using a downloaded database must then load the newer release. A cached lookup can add another delay.

An API can give a checker access to the supplier's current service, while a downloaded database remains a snapshot until it is replaced. Neither delivery method guarantees that a recent network change has already been discovered and accepted.

Update schedules can also differ within one company. DB-IP, for example, describes monthly Lite releases and daily updates for its commercial databases. That difference helps explain why two services displaying the same supplier's name may not use equally recent data. The date you opened a checker is not the date its database was built.

Submitting a correction begins a review; it does not order an immediate change. MaxMind evaluates requests against several sources and does not guarantee acceptance. Once an accepted change reaches a database release, a downstream checker still needs to use that data. A correction accepted by one supplier does not require other suppliers to adopt it.

This separates two possible explanations for an unchanged result: the service may still use an older record, or the data supplier may have retained its assessment. Waiting may help while an accepted change reaches downstream services. It will not, by itself, reverse a rejected correction. “All checkers will agree after the next update” is not a promise a proxy seller can safely make on that basis.

Which result should you use?

Start with the question you need answered. To establish what a particular database reports, use that supplier's relevant product and identify the field. To understand whether different sources agree, compare a small set of named datasets for the same IP. To determine whether a proxy works for your task, test the destination website as well.

These checks answer different questions. A website may use another IP dataset, a different version or additional location signals. Conversely, a different language, currency or access error on that website does not by itself reveal which country it assigned to your IP.

When reporting a disagreement, preserve the exit IP, the time of the check, the checker name, the named data supplier and the country or city returned. Add the product and database date when shown. This gives support a specific record to investigate instead of an unspecified claim that “the internet says this IP is wrong.”

If several addresses share the same location record, replacing one with another from that group can reproduce the disagreement. A useful replacement needs to satisfy the relevant location test, not merely have different digits. Equally, a result that matches one database does not promise matching treatment on every website.

The useful outcome is a traceable answer: this exit IP, in this data product, at this time, has this location. That lets a buyer and a provider agree on what was checked, identify where they disagree and choose an address that meets the actual requirement.