Building a country selector dropdown? Populating regional shipping options? Validating international addresses? You need reliable country data, and the API you choose matters more than you might think.

We evaluated five popular country data APIs on coverage, data depth, reliability, and pricing. Here's what we found.

Best for: Quick prototypes and simple country lookups

REST Countries has been the go-to free country API for years. No API key required, decent data structure, and it covers all 250 countries with basic information like capital cities, currencies, languages, and regional classifications.

What it does well:

• Zero-friction setup (no authentication)

• Clean REST endpoints

• Solid coverage of basic country metadata

• Multiple query options (by name, code, region, currency)

The concerns: REST Countries has experienced documented ownership transitions and periods of instability. The project changed hands multiple times, and developers have reported intermittent downtime. For production applications where uptime matters, this unpredictability is a real consideration.

The data is also relatively shallow. You get country-level information, but no subdivisions (states, provinces) and no city data. If you need to build a cascading country-region-city selector, you'll need to look elsewhere.

Pricing: Free, unlimited requests (in theory)

Best for: Academic research and applications requiring maximum geographic depth

GeoNames is the heavyweight of geographic databases. With over 11 million place names and comprehensive coverage of administrative divisions worldwide, it's unmatched in raw data volume.

What it does well:

• Massive database covering everything from countries to neighborhoods

• Full postal code database

• Elevation data, timezone information, and Wikipedia links

• Historical and alternate name data

The tradeoffs: The API design shows its age. Responses come in XML by default (JSON requires a parameter), the endpoint structure is inconsistent, and documentation can be challenging to navigate. You'll likely spend significant time writing wrapper code.

Rate limits are strict on the free tier (10,000 credits per day, 1,000 credits per hour), with different operations costing different credit amounts. Premium data subscriptions cost approximately €840/year.

Pricing: Free (10K credits/day with attribution), Premium data ~€840/year

Best for: City-centric applications and autocomplete features

GeoDB Cities focuses specifically on city data, offering a modern GraphQL API alongside REST endpoints. If your primary need is city information rather than country metadata, it's worth considering.

What it does well:

• Clean, modern API design with GraphQL support

• Strong city search with prefix matching for autocomplete

• Population data and geographic coordinates

• Distance calculations between cities

• 800K+ populated places worldwide

Limitations: Country and region data exist mainly as supporting context for cities rather than as first-class resources.

Pricing: Free (rate-limited), Pro $20/month, Ultra $60/month

Best for: Teams already using the apilayer ecosystem

Countrylayer is part of the apilayer family (alongside currencylayer, ipstack, and others). If you're already paying for other apilayer services, consolidating might make sense.

What it does well:

• Consistent API design if you're familiar with apilayer

• Reliable infrastructure

• Good country-level data including calling codes and flag images

Limitations: The free tier is extremely limited at 100 requests per month. There's no region or city data—strictly country-level information. Pricing can add up quickly if you need other apilayer services.

Pricing: Free (100/month), Basic $10/month, Professional $40/month

Best for: Production applications needing countries, regions, and cities in one API

World Data API takes a unified approach, providing country, region, and city data through consistent endpoints. All data types are available on all tiers, with rate and quota limits differentiating plans.

What it does well:

• Full ISO 3166-1 and ISO 3166-2 compliance

• Hierarchical data model (country > region > city)

• Consistent response structure across all endpoints

• Bundles additional data: holidays, business days, timezones, astronomy

Data coverage:

• 249 countries with comprehensive metadata

• 5,053 ISO 3166-2 subdivisions (states, provinces, territories)

• 12,103 cities with population and coordinate data

The API design prioritizes developer experience with predictable endpoints, consistent pagination, and clear error messages. Note that city coverage is more limited than GeoNames or GeoDB — focusing on major cities rather than every village.

Pricing:

All five APIs cover the basics: country name, ISO codes, capital, population, and region. Differences emerge in secondary data:

This is where options narrow significantly:

• REST Countries: None

• GeoNames: Comprehensive but complex to query

• GeoDB Cities: Available as city context, not standalone

• Countrylayer: None

• World Data API: Full ISO 3166-2 coverage with dedicated endpoints

If you need to populate a state/province dropdown after a user selects a country, your realistic options are GeoNames or World Data API.

• REST Countries: None

• GeoNames: 11M+ places (includes villages, neighborhoods)

• GeoDB Cities: 800K+ populated places, strong search

• Countrylayer: None

• World Data API: 12,103 cities (major cities only), hierarchical querying

API reliability matters for production applications. Here's the current state:

REST Countries has had well-documented stability issues stemming from ownership changes. Multiple GitHub issues and developer forum posts reference unexpected downtime.

GeoNames has been consistently available for years, though the service can be slow during peak usage on free tier accounts.

GeoDB Cities and Countrylayer both run on established infrastructure with generally good uptime records.

World Data API is actively maintained with version guarantees and documented uptime commitments.

• You're building a prototype or hobby project

• You only need basic country data

• You don't want to deal with API keys

• Occasional downtime is acceptable

• You need maximum geographic depth

• You're doing academic or research work

• You have engineering resources to work around API quirks

• You need postal code data

• Cities are your primary focus

• You need city autocomplete functionality

• You want a modern API design

• Country/region data is secondary

• You're already invested in the apilayer ecosystem

• You only need country-level data

• You value vendor consolidation

• You need countries, regions, and cities from one source

• ISO compliance is important

• You want country data without paying

• You're building a production application that needs reliability

Here's how a typical country-region-city cascade looks with different APIs:

With GeoNames (3 different endpoint patterns):

GET geonames.org/countryInfoJSON
GET geonames.org/childrenJSON?geonameId={countryId}
GET geonames.org/searchJSON?country={code}&featureClass=P

With World Data API (consistent pattern):

GET /countries
GET /countries/{code}/regions
GET /countries/{code}/regions/{regionCode}/cities

The difference in developer experience compounds as your application grows.

The country data API space has a clear divide: free options with limitations, and paid options with better reliability and depth.

For simple country lookups in non-critical applications, REST Countries remains functional despite its stability concerns. For anything requiring subdivisions, cities, or production-grade reliability, you'll need to evaluate the paid options based on your specific data requirements and budget.

World Data API offers a middle path with free country data and reasonable pricing for full access, making it worth evaluating if you need more than basic country information but don't require GeoNames' massive geographic database.

Whatever you choose, abstract your API calls behind a service layer. Country data APIs have a history of changing ownership, pricing, and availability. A clean abstraction makes switching providers painless when—not if—you need to.