You have an IP address. You want to know the country, the city, the ISP, the timezone — anything that puts the user on a map. Sounds simple, and in 2026 it should be. The catch is that there are at least five different ways to do this, each with very different trade-offs in accuracy, latency, infrastructure cost, and operational headache.

This post compares the five approaches developers actually use, with the honest pros and cons of each. If you’ve ever wondered which one is right for your case, this is the field guide.

Why It’s Not Just “Look It Up”

IP geolocation looks simple from the outside — IP in, location out — but the data underneath is the result of constant work. There is no central registry that says “this IP is in Paris.” Geolocation databases are built from a mix of:

RIR allocation records (which give you country-level data and registration org).
BGP routing tables (which tell you the ASN — the operating network).
Active probing (latency triangulation from many points to estimate location).
Mobile/Wi-Fi positioning data (paid datasets, telco partnerships).
User-submitted corrections (large providers feed reports back into their data).
WHOIS, traceroute, DNS hints (PTR records sometimes leak city codes).

The provider that does all of this well — at scale, in close to real time — is the provider that produces accurate data. The free databases often skip some of these inputs, which is why they’re free.

Method 1: Free GeoLite2 Database (MaxMind)

The classic free option. MaxMind publishes the GeoLite2 City and Country databases under a Creative Commons license. You download the .mmdb file weekly, point a client library at it, and look up addresses in-process.

Pros:

Free.
No network call — sub-millisecond lookups.
No rate limits.
Works offline.

Cons:

Significant accuracy degradation since 2019. Independent benchmarks have shown GeoLite2 city-level accuracy dropping into the 60–70% range, where commercial competitors are 80–90%+.
Mandatory account + license key since late 2019. You can no longer just wget the file.
You’re responsible for keeping it updated. A 6-month-old MMDB is meaningfully less accurate than a 1-week-old one.
No SLA, no support, no contractual data quality.
No ASN data in the free Country tier (you need the separate ASN database).

Best for: small projects, hobby work, anything where you’re already maintaining the operational overhead and accuracy is a “nice to have.” Not recommended for any production system where geo-accuracy affects revenue (geo-routing, fraud detection, compliance).

Method 2: Commercial GeoIP2 Database (MaxMind, IPinfo, etc.)

Same shape as Method 1 — an offline .mmdb file your code loads — but paid, larger, and more accurate. Updated daily or sub-daily. Includes city-level data, ASN, ISP, organization, sometimes confidence scores.

Pros:

Sub-millisecond lookups, no network call.
Better accuracy than the free tier (varies by provider — typically 85–95% at country level, 70–85% at city level for the better ones).
Predictable cost — flat license fee, no per-lookup pricing.
Works offline and during partial outages.

Cons:

You still have to update it. Daily downloads, monitoring, fallback handling. This is real operational work.
Binary file size. The city MMDB is hundreds of MB, which has to fit in your deployment image and memory.
Cold start cost. Spinning up new instances means re-loading the MMDB into memory. Not free at scale.
Per-server licensing. Most commercial offline licenses are per-server, which gets expensive at scale.
Data is days old by definition. New BGP announcements, new ranges, recently moved networks — your data won’t reflect them until the next update.

Best for: latency-critical paths where the network round-trip of an API is unacceptable. Game servers, ad auction systems, real-time bidding.

Method 3: REST API (Hosted IP Geolocation)

The modern default for most developers. You send an HTTP request to an API endpoint with the IP you want to look up. The API returns JSON with country, city, ASN, organization, timezone, and so on.

Pros:

No database to maintain. No downloads, no version drift.
Data is always current. The provider updates their data continuously; you get the freshest data on every call.
Tiny footprint in your code. A single fetch() call.
Per-request pricing. Pay only for what you use. Often there’s a generous free tier.
Includes enrichments you wouldn’t get from a raw MMDB — VPN detection, threat intel, currency, calling code, etc.
Easy to scale to global edge — most modern IP geo APIs run their endpoints on CDN-style edge networks (we do).

Cons:

Adds a network call to your request path. At an edge POP this might be 5–20ms; from a poorly located datacenter, much more.
Failure mode handling. What happens if the API is down? You need a fallback.
Rate limits and quotas on free/lower-tier plans.
Per-request cost scales with traffic. At very high QPS, costs can dominate.

Best for: most use cases. If you’re building a product and need IP geo, this is almost always the right starting point. The Ip2Geo API falls into this category — free tier of 1,000 conversions/month, fast edge endpoints, includes ASN and flag data inline. See pricing for higher tiers.

Method 4: Client-Side (Browser Geolocation API)

A completely different approach: don’t geolocate the IP at all. Ask the browser, via the W3C Geolocation API, for the user’s actual location.

navigator.geolocation.getCurrentPosition((pos) => {
    console.log(pos.coords.latitude, pos.coords.longitude)
})

This uses GPS / Wi-Fi / cellular triangulation — much more accurate than IP-based geo, often within meters.

Pros:

Wildly more accurate for the use cases where the user’s actual physical location matters (maps, “near me” features).
Free. No backend cost at all.
Doesn’t depend on the IP at all — works for VPN users, NAT-ed users, mobile users.

Cons:

Requires user permission. The browser shows a prompt. Many users decline.
Doesn’t work for server-side decisions. You only get the location after the user has loaded your page and granted permission.
Doesn’t tell you what network/ASN they’re on — useful only for “where on a map,” not “who is this user.”
Doesn’t give you currency, language, timezone metadata without additional logic.
Fragile. Browser permissions can be revoked, denied by default in corporate environments, blocked by extensions.

Best for: features where the user opts in — finding nearby stores, distance-based search, ride-sharing pickup. Not a substitute for IP geolocation when you need server-side decisions before the user has loaded anything.

Method 5: Server Hint Headers (CDN-Provided)

If your traffic flows through a major CDN — Cloudflare, AWS CloudFront, Fastly — the CDN often injects geo headers into the request before it hits your origin. For example, Cloudflare adds CF-IPCountry, CF-IPCity, and (with the right plan) CF-IPLatitude and CF-IPLongitude.

CF-IPCountry: US
CF-IPCity: San Francisco
CF-IPContinent: NA

Your server reads the header and uses it directly. The CDN does the lookup using their own data.

Pros:

Effectively free — you’re already paying for the CDN.
No extra network call — the CDN does the lookup in line with the request.
Often accurate for country-level data; varies by provider for city.
Trusted by browsers and clients — already part of the request when it reaches you.

Cons:

Locks you to one CDN’s data. If you migrate, you lose the data layer too.
Limited fields. Country is universal; city, ASN, ISP are not.
No ASN/organization data out of the box from most CDNs (Cloudflare added this on higher plans).
Doesn’t work for non-HTTP traffic (TCP services, background jobs running with stored IPs).

Best for: web applications already fronted by Cloudflare or similar. Use the headers for cheap country-level personalization and fall back to a real geo API for higher-resolution data when you need it.

Direct Comparison

Method	Latency	Accuracy	Operational Cost	$ Cost	When to use
Free GeoLite2	<1ms	Medium-low	High (you manage updates)	$0	Hobby projects, prototypes
Commercial MMDB	<1ms	High	High (you manage updates)	$$	Latency-critical paths
REST API	5–50ms	High (live data)	None	$-$$ per request	Most production cases
Browser Geolocation	Variable	Very high (with permission)	None	$0	”Where on a map” features
CDN headers	0ms (in-line)	Country-good, city-varies	None	Included in CDN	Already on Cloudflare etc.

What to Pick — Decision Tree

Do you need the result on the server before the user does anything? → Method 3 (REST API) or Method 5 (CDN headers).
Is the request path so latency-sensitive that even 5ms is unacceptable? → Method 2 (commercial MMDB) or Method 5 (CDN headers).
Are you on a fast-moving product where data freshness matters? → Method 3 (REST API, like Ip2Geo). MMDBs go stale.
Do you need the user’s actual physical location (not their network’s)? → Method 4 (browser geolocation).
Just starting and exploring? → Method 3 with a free tier. Switch later if you outgrow it.

Practical Tips

A few hard-won lessons regardless of method:

Always handle “unknown” gracefully. Some IPs simply don’t have a meaningful location (newly allocated ranges, anycast addresses, satellite providers). Your code should treat “unknown country” as a valid state.
Don’t make destructive decisions on geo alone. Blocking a user based on country IP is fragile — VPNs, mobile data roaming, satellite, and corporate VPNs all confuse it. Use geo as one input among several.
Cache aggressively at your edge. If you’re calling a REST API, cache the result per-IP for at least a few minutes. The geo of an IP rarely changes minute to minute.
Use the ASN data, not just the country. “Country: US, ASN: AWS” tells you something completely different from “Country: US, ASN: Comcast.” The ASN often matters more than the country.
Test edge cases. Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, a known IPv6, an obscure country, an IP that just moved between ASNs. The day you ship is the day weird IPs start arriving.
Plan for IPv6. Some geo databases under-cover IPv6 ranges. Verify your method works for both protocols.

The Bigger Picture

IP geolocation is an enrichment, not a source of truth. The IP gets you to a country and an ASN. The user’s actual context — language preference, payment method, intent — needs more than just the IP. But IP geo is the cheapest signal you have, available before the user has done anything, and useful in dozens of small ways.

If you just want to get started, the Ip2Geo API gives you 1,000 conversions per month free, returns country/city/ASN/timezone/currency in a single call, and works from any backend or edge function. Or, if you want to feel out what’s possible first, the IP lookup tool lets you query individual IPs in your browser and see exactly what’s in a response. Once you’ve seen the data shape, the integration is one HTTP call away.