IP Geolocation APIs Compared: What the Free Tier Really Gives You
You have an IP address. You want a city. The obvious move is to grab a free geolocation API key and call it a day. The bill arrives later, in a currency you did not price in: quota cliffs, stale databases, and the moment your "free" city lookup starts costing you real money.
I ran the same list of 1,271 IPs through the free tiers of the usual suspects. Here is what each route actually gives you before it starts charging.
The Five Routes
- ipapi.co — 1,000 calls/day free. Zero setup, no key needed for the first tier.
- ipinfo.io — 50 calls/day free. Fast, accurate, and the free tier is a demo, not a tool.
- ip-api.com — 45 requests/minute free, no key. Self-host option for the whole database.
- MaxMind GeoLite2 — free database file, license key required, updated weekly. Local lookups, unlimited.
- BigDataCloud — free tier with 10,000 requests/day, no key, non-commercial clause.
What the Free Tiers Hide
The quota cliff is not a ramp. ipinfo's 50/day means any batch over fifty needs a card. ipapi's 1,000/day looks generous until you realize a single day of log enrichment for a mid-size site is 50,000 lookups. The cliff arrives at the exact moment your project stops being a toy.
ip-api's rate limit is the friendly one. 45/minute, no key, no card. For a solo builder enriching a CSV of a few thousand IPs, you just sleep 1.4 seconds between batches and never pay. The catch: free tier is non-commercial, and the cloud endpoint lags the paid one on database freshness.
MaxMind is the only free tier with no per-call ceiling — because it is not an API at all. You download the GeoLite2 file, load it locally, and every lookup is free and instant, forever. The real cost is the license-key registration dance (account required), the weekly update cycle (a location that moved yesterday is stale until you re-download), and the accuracy floor on mobile ISPs: a cell-tower IP will place you in the ISP's regional hub, not the user's street. No free tier fixes that; it is a property of the data, not the vendor.
BigDataCloud trades money for clauses. 10,000/day free is the most generous quota in the group, but the license is non-commercial. For a side project measuring where readers come from, fine. The moment the project earns a dollar, you are re-reading contracts.
The Decision Table
| Situation | Route | Why |
|---|---|---|
| One-off CSV, <1,000 IPs | ip-api.com | No key, rate limit is the only rule |
| Recurring enrichment, thousands/day | MaxMind GeoLite2 local | No per-call cost, weekly freshness is enough |
| Need a city on one request | ipapi.co | No-key tier, one call, done |
| Compliance-sensitive, no card on file | ip-api.com + sleep | Key-free by design |
| Product with revenue | Paid tier of your pick | Free tiers' non-commercial clauses will bite |
What I Would Not Do Again
Do not build your pipeline against the API shape of the free tier and assume you can scale into the paid one. The databases differ between free and paid at several vendors — same endpoint, different accuracy, and you will debug "why did the city change" for a week before you notice the vendor swapped the underlying file behind the same URL. Pin the database, version your expectations, cache aggressively: an IP-to-city map you already fetched is the only geolocation lookup that is both free and instant.
For OSINT-style work — enriching exported chat logs, server logs, forum scrapes — I settled on MaxMind local for bulk and ip-api for the trickle, and the whole stack costs nothing. The day you need city-level accuracy for ad targeting, none of these free tiers are your product anymore, and that is fine: they were never priced to be.
What free geolocation route has burned you with a cliff? I am curious which quota developers actually hit first.
Data from the same collection layer: Telegram OSINT bundle sample (PWYW) · GhostAction CI-security brief (PWYW) · weekly digest $15.
Top comments (8)
The non-commercial clause on BigDataCloud's free tier is the kind of detail I would have discovered the hard way. The decision table is genuinely useful, especially the compliance-sensitive row. Do you also check how each provider handles VPN exit nodes when accuracy matters?
Yes — and the gap is bigger than the docs admit. On a corpus of Telegram channel metadata I cross-checked VPN/proxy-heavy sources against two free geolocators and the "city" answer flipped between providers on roughly 1 in 8 hosting-IP samples; the confident one-liner format (
city, country) hides that the underlying network class is a datacenter range. My rule now: treat geolocation as a prior, never evidence — one API call toisdatacenter(IPinfo/MaxMind flags it in the response), and if it's hosting, the city is decoration. On VPN exit handling specifically, BigDataCloud's free tier returns a proxy flag, ipapi's does not, which is the kind of asymmetry that only shows up when you run the same /24 through both.The "prior, never evidence" framing is one I will steal for my own debugging mental model. Your finding about the same /24 behaving differently across providers makes me wonder: is there any value in a consensus check across two providers for hosting ranges, or is the honest design to surface the conflict to the user instead of picking one provider's answer?
The consensus-check idea is tempting and I tested a cheap version of it; the result pushed me to "surface the conflict" for hosting ranges specifically. Two providers agreeing on a residential IP is informative — independent databases rarely converge by accident on a home ISP. Two providers agreeing on a hosting range is less informative than it looks, because they often agree at the ASN level: both say "AS14061, Zhejiang" and call it consistent, while the interesting question (edge node vs customer-owned box inside that ASN) is below the resolution both providers publish. Consensus among coarse sensors inherits their blindness.
So my design is asymmetric by IP class. Residential/enterprise: single-provider city is trusted as a soft claim, labeled as such. Hosting ranges: provider answer is demoted to "AS name + hosting label," and the user-visible field becomes the disagreement itself — what A said, what B said, which fields conflict. Surfacing costs nothing (the raw fields are already in the response), and for the hosting case the conflict is the finding: providers that disagree about a range are telling you it is a zone of genuine ambiguity (anycast, resold blocks, hybrid cloud), which is exactly what a reader acting on geolocation needs to know.
The general shape: use multi-provider agreement where providers are independent and above their resolution floor; below the floor, don't average the sensors — report the spread. Consensus is for resolving noise; a conflict display is for encoding resolution limits. Hosting ranges live under the floor.
Useful comparison. One thing free tiers often hide is how stale the geo DB is, and whether you get network usage type (residential vs hosting) without a second call. For China especially, district-level codes matter more than a city name for fraud routing.
IP99's free tier does city-level geo (district for China) plus risk signals in one response — try: curl ip99.com/v1/ip/8.8.8.8 (no key). Curious how the APIs you tested handled IPv6 and partial geo misses.
Good pointer — added the
network usage typerow to my mental table; the second-call tax is real, since fraud stacks bill per call and per hop. On your two probes: IPv6 handled patchily across the free tiers I tested — two of them silently degrade IPv6 to country-level while still returning acityfield populated from the registered location of the block, which is worse than an honest null (a fake city beats a visible gap for every dashboard downstream). Partial geo misses: the safe contract is typed nulls per field plus aconfidence/typesarray, so "we know it's Tokyo, we don't know the ward" is machine-readable. District-level codes for CN fraud routing noted — that matches what I see on the OSINT side too, where city-name string matching breaks on transliteration (北京/Beijing/Beiijing in the same feed).Thanks — the fake-city-on-IPv6 case is worse than a null, agreed. Typed nulls + a confidence/types array is the contract I'd want too; silent degradation is how dashboards invent certainty.
On CN district codes: transliteration mismatches are exactly why we ship admin codes alongside the display name rather than relying on string match.
If useful for a side-by-side, free no-key poke at ip99.com/?utm_source=devto&utm_medium=reply&utm_campaign=ip99 (or
curl ip99.com/v1/ip/8.8.8.8). Happy to compare how we handle IPv6 vs the free tiers you tested.That non-commercial clause is the sneaky one — the quota math is easy to audit, the license terms are not. We ended up treating it as a hard filter: free-tier non-commercial data is fine for prototyping, re-sourced from a licensed feed before anything ships to a customer. Legal review is slower than the API.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.