Free IP geolocation APIs

IP geolocation is the most over-trusted data source in web development. It is genuinely useful for picking a default currency or pre-filling a country dropdown. It is genuinely unsuitable for anything where being wrong matters, and it is wrong far more often than people expect.

The shortlist

What accuracy actually means here

Providers advertise "99% accurate", and that number is true — at country level. It collapses as you zoom in.

Country     95–99%   reliable enough to act on
Region      70–85%   usable as a default, not a fact
City        50–75%   frequently wrong, often by a lot
Postcode    <50%     do not build on this
Lat/long    centroid of a region, not the user

That last line catches people out. When an API returns coordinates, it is usually handing you the centre of the city or country it guessed, not a position. Several thousand people resolve to the exact same point. There is a well-documented case of a farm in Kansas receiving years of harassment because it sat at the geographic centre of the United States, and was therefore the default answer for every IP that could not be placed more precisely.

IPify — just the address

The narrowest API on the list, which is its virtue. No key, no rate limit stated, and it does not attempt to geolocate.

curl -s "https://api.ipify.org?format=json"

{ "ip": "203.0.113.42" }

const { ip } = await fetch('https://api.ipify.org?format=json').then((r) => r.json());

Use this when all you need is the address, for example to display it or to pass it to your own backend.

ipapi.co — location, from the browser

Returns a full location record and sends CORS headers, which is what makes it usable client-side. Called with no IP, it geolocates the caller.

curl -s "https://ipapi.co/json/"
curl -s "https://ipapi.co/8.8.8.8/json/"

{
  "ip": "8.8.8.8",
  "city": "Mountain View",
  "region": "California",
  "country_code": "US",
  "currency": "USD",
  "timezone": "America/Los_Angeles",
  "org": "GOOGLE"
}

The genuinely useful fields are country_code, currency and timezone — all three are safe defaults that the user can override. city is the one to be sceptical of.

const geo = await fetch('https://ipapi.co/json/').then((r) => r.json());
form.country.value = geo.country_code;   // a sensible default
form.currency.value = geo.currency;      // also fine
// do not silently trust geo.city

ip-api — the most detail, with a catch

Returns the richest free record, including ISP, autonomous system and proxy detection.

curl -s "http://ip-api.com/json/8.8.8.8?fields=status,country,city,isp,proxy,hosting"

{
  "status": "success",
  "country": "United States",
  "city": "Ashburn",
  "isp": "Google LLC",
  "proxy": false,
  "hosting": true
}

The hosting flag is the interesting one: it tells you the address belongs to a data centre rather than a residential connection, which is a much stronger signal than city for spotting automated traffic.

Reading the IP server-side instead

If you control a backend, you often do not need any of these. The address is already on the request — but only if you read it correctly behind a proxy or CDN.

// Express behind a reverse proxy
app.set('trust proxy', true);
app.get('/api/geo', (req, res) => {
  res.json({ ip: req.ip });
});

// Next.js route handler
export function GET(request) {
  const forwarded = request.headers.get('x-forwarded-for');
  const ip = forwarded?.split(',')[0].trim() ?? 'unknown';
  return Response.json({ ip });
}

X-Forwarded-For is a comma-separated chain, and the client is the first entry. Taking the last one gives you your own load balancer.

Cache the lookup

An IP's location does not change between page loads, so looking it up repeatedly wastes your rate limit and adds latency to every request.

const DAY = 86_400_000;
const cache = new Map();
 
async function locate(ip) {
  const hit = cache.get(ip);
  if (hit && Date.now() - hit.at < DAY) return hit.data;
 
  const data = await fetch(`https://ipapi.co/${ip}/json/`).then((r) => r.json());
  cache.set(ip, { at: Date.now(), data });
  return data;
}

Where the data actually comes from

Knowing how IP geolocation is produced explains both why it works at all and why it fails the way it does.

There is no registry mapping addresses to places. What exists is a set of inferences. Regional internet registries publish which organisation owns which block, which reliably gives you a country and often an organisation. Below that, providers infer location from routing behaviour, from network latency measurements between known points, from self-published feeds where ISPs declare where blocks are deployed, and from correlating addresses against location data volunteered by applications.

That stack is why country-level accuracy is high and city-level accuracy is not. Ownership is a matter of record; deployment is a matter of inference. An ISP that owns a block registered to its head office may deploy those addresses three hundred miles away, and nothing in the registry says so.

It also explains the centroid problem. When a provider can place an address in a country but no further, it has to return something, and that something is usually the geographic centre of the country or region. Thousands of unrelated addresses therefore resolve to one point. This is not a rounding artefact — it is a deliberate fallback, and treating those coordinates as a location produces a map with an implausible cluster in the middle of nowhere.

The practical consequence is to check how a result was derived where the API tells you. Several return an accuracy radius or a confidence indicator, and a radius of five hundred kilometres is the provider telling you plainly not to put a pin on a map.

Mobile, CGNAT and IPv6

Three network realities that break the assumption of one address per user, and all three are increasingly common.

Mobile networks route traffic through a small number of gateways, so a phone in one city frequently appears at the gateway's location instead. Distances of hundreds of miles are routine. Since mobile is now the majority of consumer traffic for most sites, this is not an edge case.

Carrier-grade NAT means many households share one public address, because there are not enough IPv4 addresses to go round. Any per-address logic — rate limits, allowlists, "one signup per IP" — is therefore acting on a group of unrelated people. Blocking an abusive address can block a neighbourhood.

IPv6 has the opposite property. Addresses are plentiful enough that a single device may rotate through many, and privacy extensions make this the default. Rate limiting per IPv6 address is close to useless, because the same user appears as a new visitor repeatedly. The convention is to limit on a prefix rather than a full address, which groups a subscriber's addresses together.

Taken together, these mean an IP address is a weak identifier in both directions: many people can share one, and one person can have many. Any logic that treats it as identity will misfire, and the misfires land on real users rather than on the abuse you were targeting.

Using it well, and the privacy question

Given all of the above, the honest applications are narrower than the marketing suggests, and they are still genuinely useful.

Good uses share a shape: the guess sets a default, being wrong costs almost nothing, and the user can override it. Pre-selecting a country in a dropdown. Defaulting a currency or a timezone. Choosing which of several regional sites to suggest. Showing prices in a plausible currency before someone tells you otherwise. In every case the failure mode is a small annoyance, corrected in one click.

Bad uses share the opposite shape: the guess is treated as fact and being wrong is expensive. Blocking access by region. Determining tax jurisdiction. Age or identity verification. Denying a login because the location "looks wrong" — which mostly punishes people travelling, using a VPN, or on a corporate network.

There is also a privacy dimension worth being deliberate about. An IP address is personal data under GDPR and similar regimes. Sending every visitor's address to a third-party geolocation service is a transfer of personal data to a processor, and it needs a lawful basis and a mention in your privacy policy like any other. Doing the lookup server-side, caching by address, and storing only the derived country rather than the address itself reduces both the exposure and the obligation. Where the only thing you need is a sensible default, the browser can often tell you more cheaply and more accurately: Intl.DateTimeFormat().resolvedOptions().timeZone gives a timezone with no request and no third party involved at all.

Choosing

You only need the address. IPify.

Browser-side defaults for currency, timezone or country. ipapi.co, because of CORS.

Server-side, and you want ISP or hosting detection. ip-api, over HTTPS if you upgrade, or ipwhois.

You control the backend. Read X-Forwarded-For and skip the third party entirely.

For turning an address or place name into coordinates — a different problem with much better accuracy — see free geocoding and maps APIs, or browse the geocoding category.