The location parameter looks simple. It isn’t.
WeatherAPI accepts a location= string in several forms: city name, US ZIP, UK postcode, IP address, IATA airport code, or decimal lat/lon. Most developers start with city names because they’re readable and easy to type into a test URL. A lot of them never switch away from it. That’s worth reconsidering.
When you send location=Portland, there’s a geocoding step sitting between your string and the actual weather data. We have to resolve “Portland” to a coordinate first. There are at least two major Portlands in the US — Oregon and Maine — plus Portland in Victoria, Australia, and several smaller settlements with the same name. The geocoder picks one. It will usually pick Portland, Oregon. If your user is in Maine, that’s quietly wrong by roughly 5,000 kilometers, and your API response will look completely valid.
No error. No warning. Just the wrong city’s weather.
What the geocoding step actually does
City-name resolution works off a gazetteer — a structured place database. Ours resolves against a populated-place dataset with population weighting, so higher-population cities with the same name tend to win ties. That’s a reasonable heuristic. It’s not a reliable one for production code that might receive user-entered location strings from anywhere in the world.
US ZIP codes are more reliable than city names because a ZIP maps to a defined geographic area — the centroid of that area becomes the query coordinate. UK postcodes work the same way, and they’re actually quite precise: a full postcode like G1 1AA covers a fairly small area. IATA codes are precise too, resolving to a single airport lat/lon. But for anything outside those specific formats, you’re one ambiguous string away from silent mislocation.
The IP address case
Using location=auto:ip or passing a specific IP is convenient for quick demos. Don’t use it in production apps where accuracy matters. IP geolocation resolves to the ISP’s point of presence in many cases, not the actual device location. A mobile user in Edinburgh whose carrier routes traffic through a London PoP will get London weather. VPNs make this worse. This isn’t a WeatherAPI limitation — it’s a fundamental constraint of IP-to-location databases, which providers like MaxMind will tell you plainly if you read their accuracy documentation.
What to send instead
Decimal lat/lon. Always, for production. Format it as location=51.5074,-0.1278 — London, precisely. No ambiguity, no geocoding step, straight to station selection and any elevation corrections we apply on our end.
If your application collects location from users as a place name or address, do your own geocoding first — on your side, before the WeatherAPI call. Google Maps Geocoding API, Mapbox, Nominatim (if you’re budget-constrained and comfortable with OSM quality), or Pelias will all return a lat/lon with a confidence score you can inspect. You control the ambiguity resolution. You can prompt the user to confirm when confidence is low. Then send the resolved coordinate to WeatherAPI.
That pattern also lets you cache the geocoding result. If a user repeatedly checks weather for “home” or a saved location, you geocode once, store the lat/lon, and never run that lookup again — you’re not burning WeatherAPI quota on a step that doesn’t need to repeat.
Coordinate precision: how many decimal places actually matter
One decimal place of latitude is roughly 11km. That’s too coarse — you can easily cross into a different station catchment area or elevation band at that resolution. Two decimal places gets you to about 1.1km, which is sufficient for most weather use cases. Three decimal places (~110 meters) is more than enough precision for any current weather station network, since most METAR stations are kilometers apart anyway — sub-100m precision in your query coordinate won’t change which station gets selected. Four or five decimal places won’t break anything, but they won’t help either unless you’re doing something specific like point-level solar irradiance modeling where micro-terrain matters.
The practical floor is 2–3 decimal places. Round there and stop worrying about it.
What coordinate precision doesn’t fix
A precise lat/lon still won’t help you if the nearest reporting station sits at a dramatically different elevation from your query point. Our station selection logic applies a lapse-rate correction for elevation differences — roughly 6.5°C per 1,000m, consistent with the standard atmosphere model — but that’s an approximation of the general atmospheric gradient, not a measurement of your specific hillside. If you’re building something for mountain terrain where users are 800m above the valley METAR station, the temperature you get back is a corrected estimate, not a direct observation. Precise coordinates don’t close that gap. Only denser high-altitude station networks would, and those don’t exist at the scale most applications need.
A concrete example: what changes in the request
Two requests — one with a city string, one with coordinates for a specific location in that city:
# City string — geocoded, ambiguity risk
https://api.weatherapi.com/v1/current.json?key=YOUR_KEY&q=Springfield
# Resolved lat/lon — precise, no geocoding step
https://api.weatherapi.com/v1/current.json?key=YOUR_KEY&q=39.7817,-89.6501“Springfield” resolves to Springfield, Illinois by population weighting — but there are Springfields in Missouri, Ohio, Massachusetts, and roughly 30 other US states. If you’re serving a national app, someone in your user base is getting the wrong Springfield. You won’t see it in your error logs. You’ll maybe see it in a support ticket months later from a user who can’t figure out why the app says it’s sunny when it’s snowing outside.
When city strings are fine
For personal projects, testing, and demos — use whatever’s convenient. If you’re building a quick weekend project targeting one city you know, location=Glasgow works fine. The problem is production apps at scale with user-supplied or programmatically-generated location strings. That’s where silent geocoding mismatches accumulate into a real data quality problem.
For free-tier users just getting started: the fastest way to avoid this class of bug entirely is to run your location strings through any free geocoder once, store the result, and only ever pass lat/lon to WeatherAPI after that. Nominatim is free and handles low-volume use without trouble.
If you’re pulling locations from a database originally populated by user-entered strings, audit a sample — resolve each string independently and compare it against what you’ve been querying. The mismatch rate is usually higher than you’d expect.