N-Number vs. Mode S / ICAO24: How U.S. Aircraft Identifiers Relate

Aircraft data gets confusing quickly because one aircraft can be described by several identifiers that answer different questions.

For U.S. registry work, two of the most visible are the N-number and the Mode S address, often called the ICAO 24-bit address or ICAO24. They are related, but they are not the same field and should not be treated as interchangeable identifiers.

The distinction matters when you build software around aircraft records. A search box, database key, history model, ADS-B integration, and physical-airframe identity layer may each need a different identifier.

An N-number is a U.S. registration identifier

The FAA defines an N-number as the nationality and registration marking of a U.S.-registered aircraft. Its current formation rules are specific: after the leading N, a registration may contain one to five numbers, one to four numbers followed by one letter, or one to three numbers followed by two letters. The letters I and O are excluded, and the numeric portion may not begin with zero. (FAA N-number rules)

Examples of valid shapes include:

• N12345
• N1234Z
• N123AZ

The important software implication is that an N-number represents a registration assignment, not a permanent physical airframe.

An aircraft can receive a different registration number. An N-number can also move through reservation and reassignment processes over time. That makes the N-number excellent for the developer task "look up the current FAA record for this U.S. registration," but risky as the only lifetime identity of an aircraft.

The Grizzly Bulls N-number lookup API therefore uses the N-number as the lookup key while keeping physical-aircraft identity as a separate concept.

Mode S is a 24-bit aircraft address

The FAA defines the Mode S code as an address used by the Mode Select surveillance system and says it is sometimes referred to as the ICAO address code. FAA guidance describes the ICAO address as a 24-bit value used by Mode S transponders and ADS-B systems. (FAA registry definitions, FAA AC 20-151C)

A 24-bit value is commonly represented in different number bases. In FAA registry data, the same address is exposed in both octal and hexadecimal forms.

That means these are representations of the same underlying address, not two separate aircraft identifiers:

1Mode S / ICAO 24-bit address
2        |
3        +--> octal representation
4        |
5        +--> hexadecimal representation

The FAA Aircraft Registration Master file includes Mode S fields, and the FAA's public aircraft inquiry displays both base-8 and base-16 versions. (FAA registry download)

In the U.S., the Mode S address is tied to registration

This is the subtle part.

FAA guidance says that for U.S. civil aircraft, the ICAO 24-bit address is established as a function of the aircraft's registration number. It also warns that the address should be verified when a registration number changes. (FAA AC 20-151C)

So although a Mode S address is often described informally as an "aircraft address," it should not be treated as an immutable physical-airframe identifier in a U.S. registry database.

A useful mental model is:

1physical airframe
2    |
3    +--> registration assignment --> N-number
4                              |
5                              +--> U.S. ICAO 24-bit / Mode S address

That is not saying the N-number and Mode S address are the same thing. It is saying both are linked to the registration state rather than providing a permanent manufacturer-level identity for the physical aircraft.

This distinction becomes important in historical data. If a physical aircraft receives a new N-number, the associated ICAO address should correspond to the new registration. A database that uses the old Mode S value as an eternal physical key can therefore fragment or misjoin history.

Neither field is enough for physical-aircraft identity

When building the Grizzly Bulls aircraft data model, we deliberately avoided using either the N-number or Mode S address as the canonical physical-aircraft key.

We also avoided treating the FAA record's UNIQUE ID as durable airframe identity. That field identifies a source registry record, which is not necessarily the same thing as the physical aircraft across registration assignments.

For exact source-level matching, our current rule uses the FAA manufacturer code plus manufacturer serial number when both are present. If the required inputs are missing, the airframe identity remains unresolved.

That means we do not fall back to:

• N-number;
• Mode S / ICAO24;
• owner name;
• make/model text;
• fuzzy string matching; or
• another convenient field that happens to be populated.

The result is intentionally conservative. A false unresolved identity is inconvenient. A false merge between two aircraft can corrupt years of history.

Mode S lookup is a separate exact operation

The Grizzly Bulls aircraft API returns both Mode S representations in an exact N-number response:

• aircraft.modeSCodeOctal
• aircraft.modeSCodeHex

It also supports a separate exact machine lookup by the six-hex-digit ICAO24 / Mode-S address:

1GET /v1/aircraft/icao24/{hex}

The hex input is normalized to uppercase and must contain exactly six hexadecimal digits. A successful lookup returns the same current-aircraft response contract as exact N-number lookup.

Keeping the operations separate is deliberate. An N-number is the U.S. registration identifier; ICAO24 is the registry-associated surveillance address. Supporting both lookup directions does not make either one a permanent physical-airframe identity, and the ICAO24 route does not imply ADS-B positions, flight tracking, transponder history, or global aircraft coverage.

The N-number lookup guide remains the integration guide when registration number is the starting identifier. The machine-readable OpenAPI contract documents the ICAO24 operation.

N-number validation belongs at the boundary

The FAA's formation rules are simple enough to describe but still worth enforcing exactly.

For the current API, accepted input is normalized to uppercase and an optional display-style dash after N is removed. The canonical forms then follow the FAA shapes:

• one to five digits after N;
• up to four digits plus one allowed suffix letter;
• up to three digits plus two allowed suffix letters;
• no leading zero; and
• no I or O suffix letters.

Keeping that validation at the request boundary has two benefits.

First, callers get a deterministic 400 invalid_request instead of an ambiguous "not found" response for a malformed identifier.

Second, the database only receives normalized keys. That avoids quietly creating several spellings of the same registration in caches, logs, or downstream joins.

Identifier conversions should not become identity assumptions

Developers often have a legitimate reason to move between N-number and ICAO24 representations.

For example, an ADS-B integration may receive a hexadecimal ICAO address while a registration workflow starts with an N-number. FAA guidance establishes a relationship between them for U.S. civil registrations.

But being able to convert or correlate identifiers does not mean they have the same semantic role.

A robust aircraft model keeps at least these concepts distinct:

This is the same design principle that appears in financial data systems: a ticker, CUSIP, legal security, issuer, and company may all be related without being interchangeable keys.

Registration changes are where weak identity models break

Many identifier mistakes stay invisible while an aircraft keeps the same registration for years.

The edge case arrives when something changes.

Suppose an application has stored:

• one N-number;
• one Mode S hex value;
• a manufacturer/serial pair; and
• historical observations.

If the registration changes, the application has to decide which fields describe the same physical aircraft and which fields describe the old registration assignment.

A model that equates "aircraft = N-number" may create a second aircraft.

A model that equates "aircraft = Mode S address" can have a similar problem because FAA guidance expects the address to correspond to the new U.S. registration.

A model that stores registration and airframe identity separately can instead close the old observed registration interval, begin a new registration relationship, and keep the resolved airframe identity stable when the evidence supports it.

That is why identifier semantics matter before you build history.

The practical rule

For U.S. FAA registry software:

• use the N-number when the user means the registration;
• use Mode S / ICAO24 when the user means the surveillance address;
• do not treat either as automatic permanent physical-aircraft identity; and
• preserve the relationship between them as time-varying registration evidence.

The FAA provides both identifiers. The engineering work is deciding what each one is allowed to prove.

If your application starts from a U.S. registration number, the Grizzly Bulls N-number lookup API returns the current normalized aircraft record, including the registry's Mode S octal and hexadecimal fields. If it starts from a known six-digit ICAO24 address, the versioned machine API supports exact lookup at /v1/aircraft/icao24/{hex} and returns the same current-aircraft contract.