Snow water equivalent — the depth of liquid water you’d get if you melted a given snowpack — doesn’t appear in our API responses, or in most weather APIs at all. If you’re building anything that depends on actual water content (irrigation scheduling, snowmelt runoff estimation, avalanche risk proxies, reservoir yield modeling), that absence matters.
The totalsnow_cm field tells you how many centimeters of snow are forecast to accumulate. But snowpack density varies by almost an order of magnitude depending on temperature and humidity at time of fall. New snow in a cold, dry airmass at -15°C might have a snow-to-liquid ratio (SLR) of 20:1 or higher — 20cm of snow, 1cm of water. Wet, heavy snow just below freezing can be closer to 6:1 or 7:1. A lot of application code silently assumes a fixed 10:1 ratio when converting snowfall to water content. That default can be off by a factor of two or three in either direction.
Why SWE Isn’t in the Response
SWE is a derived quantity, and computing it well requires information that isn’t always available from the underlying model output we’re ingesting. HRRR and NAM both carry SWE fields internally — it’s a native prognostic variable in those models — but it doesn’t always map cleanly to a normalized API field the way wind or temperature does. ECMWF’s deterministic runs carry snowpack water content too, and exposing it consistently across all locations has been lower priority than getting core fields right first.
There’s also a representativeness problem. SWE is highly sensitive to whether snow on the ground is fresh or has already compacted. A model might output a SWE value that’s plausible for an open field but wrong for a forest stand or a rooftop. Surfacing that figure without the caveat felt like it would mislead more users than it would help. We’d rather give you the snowfall field and let you reason about the density than hand you an SWE number that implies more precision than actually exists.
The Back-Calculation Approach
The most defensible method for estimating SWE from API fields uses temperature and humidity at snowfall time to approximate SLR. The relationship is grounded in work by Judson and Doesken (2000) and later refined by Roebber et al. (2003) at NCAR: SLR correlates most strongly with air temperature at 850 hPa, but near-surface temperature is a reasonable proxy when upper-air data isn’t available.
Here’s a simplified but usable SLR lookup you can wire to WeatherAPI’s temp_c and humidity hourly fields:
function estimateSLR(tempC, relativeHumidity) {
// Simplified from Roebber et al. (2003) temperature-based SLR ranges
if (tempC > -1) return 6; // Wet, heavy snow near freezing
if (tempC > -3) return 8;
if (tempC > -5) return 10; // "Classic" 10:1 zone
if (tempC > -9) return 14;
if (tempC > -14) return 18;
return 22; // Cold, dry, very light snow
}
function estimateSWEmm(totalSnowCm, tempC, relativeHumidity) {
const slr = estimateSLR(tempC, relativeHumidity);
return (totalSnowCm * 10) / slr; // Convert cm to mm, divide by ratio
}
So for 10cm of forecast snow at -8°C, you get an SLR of 14 and an estimated SWE of about 7.1mm. The naive 10:1 default gives you 10mm — a 40% overestimate of available water content.
Relative humidity matters at the margins. Very low RH (under 60%) at cold temperatures tends to push SLR higher — snow crystals are more dendritic and trap more air. At RH above 85% near freezing, you’re likely dealing with wet snow even if temperature alone would suggest otherwise. A humidity correction:
function estimateSLR(tempC, rh) {
let base;
if (tempC > -1) base = 6;
else if (tempC > -3) base = 8;
else if (tempC > -5) base = 10;
else if (tempC > -9) base = 14;
else if (tempC > -14) base = 18;
else base = 22;
// Low RH inflates ratio slightly at cold temps
if (rh < 60 && tempC < -5) base = Math.min(base + 3, 25);
if (rh > 85 && tempC > -4) base = Math.max(base - 2, 5);
return base;
}
This won’t beat a full NWP-derived SWE field. But it’s considerably better than a fixed ratio, and the inputs are already in every hourly forecast response you’re pulling anyway.
When This Breaks Down
A few failure modes worth knowing upfront.
First: totalsnow_cm is a cumulative field over a forecast period, not an instantaneous rate. If you’re applying an SLR correction, you want to match the temperature at the hour snow is actually falling, not the end of the accumulation window. For a storm that starts at -2°C and drops to -10°C midway through, a single correction applied to the total will be wrong. You’d need to compute per-hour and sum.
Second: this handles fresh snowfall only. It says nothing about existing snowpack that has been sitting for days and started to sinter and compact. If you’re modeling total basin SWE rather than storm-event SWE, you need a different approach — NOAA’s SNODAS product is the starting point for US locations.
Third: elevation matters in ways this doesn’t fully capture. Snow at higher elevations falls through colder, drier air for longer before reaching the surface, which affects crystal structure. Our lapse-rate correction handles temperature, but the humidity field you’re pulling is a surface observation. In steep terrain, treat these results as directionally useful, not precise.
Practical Use Cases This Actually Unlocks
For agriculture: estimating available snowmelt water heading into spring is a real operational question for farms in snow-belt regions — western US, Canadian prairies, parts of Europe. The difference between 7mm and 10mm of SWE across a 100-hectare field is not trivial when you’re planning irrigation reserves.
For construction and structural load: a flat roof rated to 1.5 kPa can’t distinguish between 15cm of light powder (roughly 75 kg/m²) and 15cm of wet snow (closer to 200 kg/m²). The condition code says “heavy snow” in both cases. SLR-corrected SWE lets you build a meaningful load proxy — not an engineer-grade calculation, but a risk flag worth surfacing.
For ski and outdoor recreation: SLR is literally how ski resorts characterize snow quality. “Champagne powder” is a high-SLR event. Knowing the ratio from forecast fields before the storm arrives is directly useful for travel timing decisions.
None of this requires anything beyond what you already get from the hourly forecast endpoint. If you’re storing hourly snapshots for post-event analysis, log the computed SLR alongside the raw snowfall field now — it makes backtesting meaningfully easier later, especially when you’re trying to figure out whether your estimates were systematically off for warm wet events versus cold dry ones. That’s usually where the 10:1 assumption quietly does the most damage.