When building Weather & Clock Dashboard, I evaluated several weather APIs. I ended up choosing wttr.in. Here's why — and why it might be wrong for your use case.
The Options
OpenWeatherMap — The obvious choice. Free tier with 1000 calls/day. Requires API key. JSON format. Great documentation.
wttr.in — A public weather service designed for terminal/curl usage. Free, no API key, accepts city names or coordinates. Returns JSON, ASCII art, or PNG images.
WeatherAPI.com — Similar to OWM but with a slightly different free tier.
Open-Meteo — Open source weather API, completely free, no API key. Returns forecasts based on coordinates.
National Weather Service (US only) — Free, no key, but US-only.
Why wttr.in Won
1. No API key required from users
This is the biggest factor. OpenWeatherMap requires users to:
- Create an account
- Generate an API key
- Paste it into the extension settings
- Wait (new keys can take hours to activate)
wttr.in requires:
- Type your city name
That friction difference is enormous for install-to-active-user conversion. Every step you remove from setup increases activation rates.
2. Simple URL format
// wttr.in request
const url = `https://wttr.in/${encodeURIComponent(city)}?format=j1`;
Compare to OWM:
// OpenWeatherMap request
const url = `https://api.openweathermap.org/data/2.5/forecast?q=${encodeURIComponent(city)}&appid=${userApiKey}&units=metric`;
Simpler code = fewer bugs.
3. The j1 format returns exactly what I need
{
"current_condition": [{
"temp_C": "18",
"weatherDesc": [{"value": "Partly cloudy"}],
"humidity": "65",
"windspeedKmph": "20"
}],
"weather": [{
"date": "2024-01-15",
"hourly": [{"tempC": "15", ...}],
"maxtempC": "22",
"mintempC": "12"
}]
}
Current conditions plus 3-day forecast, one request.
The Tradeoffs
wttr.in limitations
Reliability: wttr.in is a single developer's project. It could go down or rate-limit requests. It's not a commercial API with SLAs.
Rate limiting: The service does rate-limit per IP. High-traffic use (many users with the same IP, like behind corporate NAT) can get blocked.
Data source: wttr.in pulls from multiple sources. Data quality varies by region.
No API key = less control: You can't increase rate limits. You're at the mercy of the service's capacity.
When to use OpenWeatherMap instead
- You're building a commercial product that needs reliability guarantees
- You need weather for non-cities (coordinates only, remote areas)
- You need hourly precision
- You have technical users who don't mind API key setup
When wttr.in makes sense
- You want zero-friction setup
- Consumer-facing tool where setup friction kills activation
- Side project or personal tool
- Casual weather display (not financial or safety-critical)
Implementation Detail: Caching
Since wttr.in doesn't have a paid tier, I implemented aggressive caching:
const CACHE_DURATION = 30 * 60 * 1000; // 30 minutes
async function fetchWeather(city) {
const cacheKey = `weather_${city}`;
const cached = await browser.storage.local.get(cacheKey);
if (cached[cacheKey]) {
const { data, timestamp } = cached[cacheKey];
if (Date.now() - timestamp < CACHE_DURATION) {
return data; // Return cached data
}
}
// Fetch fresh data
const resp = await fetch(`https://wttr.in/${encodeURIComponent(city)}?format=j1`);
const data = await resp.json();
// Cache it
await browser.storage.local.set({
[cacheKey]: { data, timestamp: Date.now() }
});
return data;
}
This means the API only gets called once per 30 minutes per user, not on every new tab open.
Current Status
Weather & Clock Dashboard uses wttr.in and it's working well. If the service becomes unreliable at scale, I'll add OpenWeatherMap as a fallback or primary option.
Install it on Firefox — source is on GitHub.
Curious what API you'd use for a consumer weather extension? Drop a comment — I'm considering adding OWM as an option.
