One airport, many codes: IATA, ICAO, city codes and names

Ask five systems for "New York JFK" and you may get five different answers: JFK, NYC, KJFK, "John F. Kennedy International Airport" and "New York (JFK)". They all mean the same place. Each exists because a different part of the travel industry needs a different kind of identifier, and products break when those identifiers are mixed up or drift apart.

This guide explains what each one is for, where it is used, and how to store them so every system gets the version it needs.

The identifiers, using JFK as the example

IATA airport codes have three letters and are what travellers see on tickets and bag tags. City codes group airports that serve the same place: NYC covers JFK and LaGuardia (LGA), so a search for "New York" can return both. Newark (EWR) is a useful edge case: it is in New Jersey and has its own city code, EWR, yet most travellers think of it as a New York airport, so many flight searches add it to New York results anyway. ICAO codes have four letters, start with a regional prefix (K for the contiguous United States, EG for the UK, RJ for Japan) and are what pilots and controllers use.

More examples

A few traps hide in this table:

• Names can mislead. Haneda's official name is "Tokyo International Airport", even though Narita also handles international flights. Showing official names alone would confuse travellers.
• A city code can equal an airport code. DXB is both Dubai International and the city of Dubai, which also includes Al Maktoum (DWC). Code that assumes "if it's a city code, it's not an airport" breaks here.
• Codes move. When the new Istanbul Airport opened in 2019 it took the code IST, and the old Atatürk Airport became ISL. When Berlin Brandenburg opened in 2020, BER, until then a city code, became an airport code too, and Tegel (TXL) closed.
• Not every IATA "airport" is an airport. Some codes belong to railway or bus stations sold as part of air itineraries, and many small airfields have an ICAO code but no IATA code at all.

Which systems use which identifier

• Booking, ticketing and check-in (reservation systems, departure control): IATA airport codes. The code on the ticket must match the code at check-in.
• Flight search and pricing (OTAs, metasearch, GDS): IATA city codes for "anywhere in London" searches, airport codes for the results.
• Airport operations and air traffic (airport operational databases, flight planning, NOTAMs): ICAO codes.
• Departure boards and apps: display names, usually city plus airport code, often translated ("München" for German speakers, "Munich" for everyone else).

The real problem: keeping them connected

The variety itself is fine; each identifier does its job. Trouble starts when every system keeps its own copy. The booking engine has one airport list, the mobile app another, the content team a spreadsheet of names, and nobody updates all three when Istanbul moves its code. Two patterns cause most bugs:

• Separate lists per system, which drift apart: the app still says Tegel after the website switched to BER.
• Hand-made mappings (IATA to ICAO, airport to city, code to name) that are correct on the day they are written and slowly rot.

A data model that keeps everything in sync

Keep one reference dataset and let each system read the identifier it needs from it:

airports
  id             -- your own key
  iata           -- 'HND'   (may be empty)
  icao           -- 'RJTT'  (may be empty)
  city_code      -- 'TYO'
  official_name  -- 'Tokyo International Airport'
  display_name   -- 'Tokyo Haneda'
  names          -- translations by language
  country, latitude, longitude
  timezone       -- 'Asia/Tokyo' (an IANA zone, not a fixed offset)

cities
  code           -- 'TYO'
  name, country, names by language

A few rules make this robust:

• Use your own ID as the key. IATA and ICAO codes can be missing, and codes like IST can move to a different airport.
• Store time zones as IANA zone names, not offsets, so daylight saving is handled correctly.
• Keep display names separate from official names, and translations separate from both.
• Refresh the dataset on a schedule and review the changes, rather than editing copies in each system.

Airlines have the same issue with codes that are shared or reused; see how to handle duplicate IATA airline codes.

Where Airhex fits

GEO Essentials gives you airports and cities as one connected dataset: IATA, ICAO and city codes, names, coordinates and time zones, updated as airports open, close or change codes. Look up a single airport with the airports API or a city's airports with the cities API, or download the full directory for your own systems.