If you've ever stared at a string like KJFK 261951Z 28014G22KT 10SM FEW250 24/12 A3002 RMK AO2 SLP167 and wondered what it means, you're not alone. METAR and TAF are the two coded weather reports that run aviation — one tells you what the weather is doing right now, the other tells you what it's expected to do next. Both look like noise until you know the field order, and then they read almost like plain English.

This guide breaks down METAR and TAF field by field, with real decoded examples, plus how to get both programmatically instead of writing your own parser.

What METAR and TAF Actually Are

METAR (Meteorological Aerodrome Report) is an observation. It's generated by a station's automated sensors (or a human observer) at fixed intervals — typically once an hour, with SPECI reports issued in between when conditions change significantly. Everything in a METAR already happened; it's a snapshot.

TAF (Terminal Aerodrome Forecast) is a prediction. It covers a specific airport for a defined validity window — usually 24 or 30 hours — and is updated every six hours by a human forecaster. Where METAR says "this is the weather," TAF says "this is what we expect the weather to do over the next day."

Both follow the same ICAO-standardized coded format, which is why pilots and dispatchers can read a station anywhere in the world without translation. The format is dense by design — it was built to fit a lot of information into a low-bandwidth teletype line — but the field order never changes, which makes it learnable.

How to Read a Raw METAR, Field by Field

A METAR is read left to right, and each group has a fixed position: station, time, wind, visibility, weather phenomena, clouds, temperature/dewpoint, altimeter, then remarks.

KJFK 261951Z 28014G22KT 10SM FEW250 24/12 A3002 RMK AO2 SLP167

Decoded:

  • KJFK — station identifier (New York JFK)
  • 261951Z — observed on the 26th of the month at 19:51 UTC ("Z" = Zulu time)
  • 28014G22KT — wind from 280° true at 14 knots, gusting to 22 knots
  • 10SM — visibility 10 statute miles (US reports use SM; most of the world reports meters, e.g. 9999 for 10 km or more)
  • FEW250 — few clouds (1–2 oktas) at 25,000 ft AGL — no weather phenomena group present here, since there's nothing significant to report
  • 24/12 — temperature 24°C, dewpoint 12°C (a leading "M" means below zero, e.g. M03)
  • A3002 — altimeter setting 30.02 inches of mercury (ICAO stations use Q for hectopascals, e.g. Q1013)
  • RMK AO2 SLP167 — remarks: automated station with precipitation sensor, sea-level pressure 1016.7 hPa

When weather phenomena are present (rain, thunderstorms, fog, snow), they show up as a coded group between visibility and clouds — intensity prefix (- light, no prefix moderate, + heavy) plus descriptor and type, like -RA (light rain) or +TSRA (heavy thunderstorm with rain).

Close-up of an aircraft cockpit instrument panel showing flight and navigation gauges

How to Read a TAF: Validity Periods and Change Groups

A TAF starts the same way a METAR does — station and issue time — but adds a validity period and then a sequence of forecast lines for how conditions evolve.

EDDF 041100Z 0412/0518 22020G35KT 9999 SCT040
  TEMPO 0412/0416 22030G40KT SHRA BKN030CB
  BECMG 0418/0420 22015G25KT
  PROB30 TEMPO 0512/0518 TSRA
  • EDDF 041100Z — Frankfurt, issued on the 4th at 11:00 UTC
  • 0412/0518 — valid from the 4th at 12:00 UTC through the 5th at 18:00 UTC
  • The base line (22020G35KT 9999 SCT040) is the prevailing forecast for the whole period
  • TEMPO 0412/0416 — temporary fluctuations expected between 12:00–16:00 on the 4th, each lasting under an hour at a time; only the listed elements (wind, showers, cloud) change, everything else holds
  • BECMG 0418/0420 — a gradual, lasting change expected sometime within the 18:00–20:00 window
  • PROB30 TEMPO — a 30–39% chance of the stated conditions (here, thunderstorms with rain) during that later window

FM groups work differently from TEMPO/BECMG: an FM group (e.g. FM1600 16010KT P6SM SKC) marks a complete reset — every element restarts as if it were a new forecast line, rather than modifying the previous one.

Aircraft cockpit navigation display used by pilots to cross-check weather and routing

Flight Categories: VFR, MVFR, IFR, LIFR

Once you've decoded a METAR or TAF, the ceiling and visibility numbers map to a flight category — the shorthand pilots, dispatchers, and flight-planning tools actually use to make go/no-go decisions:

  • VFR — ceiling above 3,000 ft AGL and visibility above 5 SM
  • MVFR — ceiling 1,000–3,000 ft AGL and/or visibility 3–5 SM
  • IFR — ceiling 500–999 ft AGL and/or visibility 1–3 SM
  • LIFR — ceiling below 500 ft AGL and/or visibility below 1 SM

The category is always set by whichever of the two values (ceiling or visibility) is more restrictive.

Getting METAR and TAF Programmatically

Hand-parsing METAR and TAF strings works fine for one airport on one screen. It breaks down fast once you're building a flight-planning tool, an EFB, or a dispatch dashboard that needs weather for hundreds of stations reliably — edge cases in remarks, regional format variants, and missing groups all add up to a parser you end up maintaining forever.

SkyLink API's weather endpoint returns METAR, TAF, winds aloft, PIREPs, and AIRMET/SIGMET data already decoded into structured JSON — no regex, no edge-case chasing. If your app also needs upper-level wind and temperature data, see our guide to winds aloft and FB forecasts.

The free tier includes 1,000 requests/month so you can wire it up and test against real stations before committing to anything. Paid plans start at $18.59/mo, and everything is available through the free trial with standard key-based auth. If you're tired of parsing raw weather strings, that endpoint is the fastest way to stop.