Five weather data providers with documented free access, what each one is actually good at, and the licensing details that decide which one fits your project.
5 providers
Key requirements listed
Sample responses
The APIs covered on this page
Free tiers and rate limits for weather services change frequently. These notes reflect published documentation at the time of writing - confirm the current terms before you build on any of them.
Weather data looks interchangeable until you build with it. Providers differ in how you locate a place, how far ahead they forecast, how often data refreshes, and - most importantly - what you are allowed to do with the result.
Start with the location problem
Every weather API needs to know where you mean, and they split into two camps. Some accept a city name and do the geocoding for you, which is convenient for a search box. Others accept only latitude and longitude, which is more precise and means adding a geocoding step. Coordinate-only APIs are usually the better long-term choice because place names are ambiguous - there are dozens of Springfields - and because you will eventually want to use the device location anyway.
Forecast horizon and refresh rate
Forecast accuracy degrades sharply with distance. A twelve-hour forecast is usually reliable, a three-day forecast is useful, and a fourteen-day forecast is closer to climatology than prediction. Match the horizon to the decision your users are making: an umbrella widget needs hours, a hiking planner needs days, and nothing consumer-facing needs two weeks.
Refresh rate matters just as much. Most global models update every one to six hours, so polling every minute wastes your quota and returns identical data. Cache the response and respect the expiry headers - some providers, Met Norway included, explicitly expect it.
The licensing question people skip
Non-commercial clauses. Several free tiers exclude commercial use entirely, and "my app has ads" usually counts as commercial.
Attribution. Some providers require a visible credit and a link. It is a small design constraint that is easier to plan for than retrofit.
Redistribution. Storing and re-serving data to your own users is often restricted even when displaying it is not.
Derived products. Turning raw data into your own forecast index may be treated differently from showing the numbers.
Units, codes and other integration details
Providers differ on default units - Kelvin still appears in more than one API - so set the unit parameter explicitly rather than converting after the fact. Weather condition codes are entirely provider-specific, which means an icon set mapped to one API will not transfer to another without a translation table. If you think you might switch providers later, write a thin adapter layer now that normalises units, condition codes and timestamps into your own shape.
Time zones deserve special care. Some APIs return UTC, some return local time, and some return both with an offset. Showing a user a forecast for 3 p.m. in the wrong time zone is the kind of bug that survives testing and fails in production.
Building without a backend
If you want a purely client-side project, you need an API that requires no secret key and sends permissive CORS headers. Open-Meteo and the two government services fit that description; key-based providers do not, because a key in front-end code is a key anyone can copy. The usual compromise is a small server route that holds the key, adds caching and returns only the fields your interface needs.
Presenting the forecast honestly
A forecast carries uncertainty, and a clean interface tends to hide it. "30% chance of rain" means something specific - roughly, that it rains on three of every ten days with these conditions - and users routinely read it as light rain, or as rain for 30% of the day. Showing a range rather than a single temperature, and a time window rather than an exact hour, communicates the underlying confidence more honestly. Also show when the data was last updated: a forecast with no timestamp looks equally authoritative whether it is ten minutes or ten hours old.
Related resources
For the general evaluation checklist, see Public APIs for Developers. If your app also displays prices, the Free Currency APIs page covers the same trade-offs for exchange rates, and Free JSON APIs is a good place to find test data while you build the interface.
Frequently asked questions
Which weather API works without an API key?
Open-Meteo, Met Norway Locationforecast and the US National Weather Service API all document key-free access. The two government services require a descriptive User-Agent header identifying your application.
Can I use a free weather API in a commercial product?
Often not. Several free tiers are explicitly non-commercial, and apps with advertising usually count as commercial. Check the terms of service rather than assuming.
