MAC Address Lookup in 2026: OUI Prefixes, I/G and U/L Bits

A MAC-48 address is six octets, 48 bits, usually written as six hexadecimal pairs. The first three octets are the Organizationally Unique Identifier, the OUI, assigned by the IEEE to a manufacturer. The last three are assigned by that manufacturer, though in practice many vendors derive them from a serial or a random source.

Hex digits are written most significant first in the textual form, but the IEEE transmits each octet least significant bit first on the wire. That mismatch is why the first octet is the only place where bit numbering confuses everyone: bit 0 in the standard means the least significant bit of that first octet as written, not the leftmost bit of the string.

Two bits in the first octet carry meaning. Bit 0 is the Individual/Group bit: zero means a unicast address for one interface, one means a group or multicast address. Bit 1 is the Universal/Local bit: zero means the address is globally administered under an OUI, one means it was assigned locally, typically by software.

Because hexadecimal digits are four bits, these two bits are always encoded in the last hex digit of the first octet. That is why the second character of the first octet is always even for a unicast address and odd for a multicast address, and why locally administered unicast addresses in the 02, 06, 0A, 0E, 12 and similar pattern show up as the first octet of randomized Wi-Fi addresses.

The OUI is a 24-bit assignment. When the U/L bit is zero, the first three octets identify the assignee, and a lookup against the IEEE registry is meaningful. When the U/L bit is one, the first three octets were chosen by the device or the operating system and no registry entry can exist, no matter how plausible the prefix looks.

The IEEE also issues 36-bit assignments under the MA-S registry, which share the first 24 bits with other assignees and add four more bits in the third octet. A lookup that only checks the first three octets will attribute those addresses to the wrong holder. If precision matters, check the assignment size before you trust the vendor name.

Modern operating systems rotate Wi-Fi addresses. iOS and macOS use a private address per network, Android randomizes per SSID, and Windows offers random hardware addresses. All of these set the U/L bit, which is the honest signal that the prefix is not a vendor allocation. Lookups that ignore the bit will produce a vendor name for a prefix that nobody was ever assigned.

Randomization also breaks assumptions in network controls. A MAC filter is not authentication, because the address is software-set on most platforms. The same property makes MAC addresses useless as a stable device identifier in analytics. If your product keys a licence or a device record on a MAC address, it will fragment on every network that rotates addresses and it can be spoofed trivially.

EUI-64 turns a 48-bit address into 64 bits in three steps: split the OUI and the NIC portion, insert FF:FE between them, and flip the U/L bit. The insertion provides 16 extra bits of length; the flipped bit keeps the universal/local meaning consistent in the 64-bit form, which is why the result is called modified EUI-64.

The result is commonly used as the interface identifier of an IPv6 link-local address, which always sits in fe80::/10 and always requires a zone index such as a scope id when you connect to it. Privacy extensions replace this identifier with a random one for global addresses, but the derived form still appears in documentation, lab setups, and device inventories.

The same 48 bits appear in at least four notations. Unix and Windows use colon-separated pairs. Windows sometimes uses hyphens. Cisco uses three groups of four hex digits separated by dots. Some tools emit uppercase, some lowercase, and some strip separators entirely. A parser should normalize all of them and reject anything that is not exactly 48 bits.

Normalization matters for comparison but not for storage of the original. Lowercase colon notation is the most portable canonical form. If you accept a bare 12-digit hex string, be explicit about it, because accepting it silently lets a user paste a 16-hex-digit identifier that is not a MAC address at all.

A good lookup distinguishes "this is malformed" from "this is locally administered" from "this prefix is valid but the assignee is not in the local registry". Collapsing all three into "unknown" wastes the caller's time, because the fixes are completely different.

Length errors are the most common: five octets, seven octets, or a 64-bit EUI-64 pasted into a 48-bit field. Character errors come next, usually an O for a zero or an I for a one from OCR. Then there are the logical cases: multicast addresses, the broadcast address, and locally administered prefixes, each of which is syntactically valid and semantically special.

For test data, always generate locally administered unicast addresses: set the first octet to 02 and keep the I/G bit clear. That combination is guaranteed not to belong to any vendor, so a fixture can never be mistaken for a real device, and a lookup tool will correctly say the prefix is local rather than invent a manufacturer.

The site's MAC tools operate on the 48-bit structure and do not claim to identify real hardware. They parse the bits, show the OUI as bits rather than as a vendor guarantee, and can derive an EUI-64 form. Note that the site does not generate Bluetooth device addresses or other 48-bit identifiers outside the Ethernet-style MAC tools, and it does not generate serial numbers at all.