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:

1. Create an account
2. Generate an API key
3. Paste it into the extension settings
4. Wait (new keys can take hours to activate)

wttr.in requires:

1. 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.