MAC Address Lookup

What the first half of a MAC address tells you

A MAC address is 48 bits, written as twelve hexadecimal digits. It splits into two halves that are decided by different people. The front half is the Organisationally Unique Identifier — a block the IEEE sold to a manufacturer. The back half is whatever that manufacturer wanted, and its only job is to be unique among the interfaces they build.

So a lookup is not a database of devices; it is a database of blocks. Given B8:27:EB:0A:1B:2C the registry can say the block B8:27:EB belongs to the Raspberry Pi Foundation. It cannot say which Raspberry Pi, who owns it, or where it is. That distinction is the whole tool, and it is why nobody can trace a person from a MAC address however confidently they claim otherwise.

The address is local, and that is not a technicality

A MAC address never leaves the network segment it was sent on. Every router rewrites it before forwarding, so the addresses your laptop sees are your own devices and your own gateway — not the servers you are talking to. The only people who can observe your MAC address are those already sharing your Wi-Fi or your switch, which is exactly the group randomisation was designed to protect you from.

MA-L, MA-M and MA-S

The IEEE originally sold one size of block: 24 bits of prefix, leaving the buyer 16.7 million addresses. That was hopelessly oversized for a company shipping a few thousand sensors, so two smaller sizes were added. They are carved out of 24-bit prefixes that the IEEE keeps registered to itself and then subdivides.

Why the longest prefix has to win

This is where most MAC lookup tools quietly go wrong. If you only check the first three octets, every MA-M and MA-S holder disappears behind their landlord. Take 00:1B:C5:00:0F:FF:

• Check 24 bits — 00:1B:C5 — and the answer is “IEEE Registration Authority”. True, and useless.
• Check 36 bits — 00:1B:C5:00:0 — and the answer is Converging Systems Inc., the company that actually made the device.

This tool tries 36 bits first, then 28, then 24, and stops at the first match. It also tells you which block matched, so you can see whether the answer came from a vendor's own prefix or from a subdivided one. If you ever see “IEEE Registration Authority” as a final answer here, it means the address falls in a subdivided prefix whose specific sub-block is not registered — not that the search gave up early.

The two bits hiding in the first octet

The two lowest bits of the very first octet are flags rather than part of the identifier. They change what the address means, and reading them explains most of the confusing results people get from a lookup.

The U/L bit is the important one for a vendor lookup, because it settles the question before the database is even opened. If it is set, the address was not assigned by any registry — so there is no vendor to find, and any table hit would be a coincidence. A few blocks registered in the 1980s, before the convention settled, still carry that bit: AA:00:04 appears in the registry under Digital Equipment Corporation. Reporting DEC for a modern virtual machine's address would be worse than reporting nothing, so this tool reports nothing and says why.

The I/G bit marks a group address — one frame delivered to many interfaces. 01:00:5E:… carries IPv4 multicast, 33:33:… carries IPv6 multicast, and FF:FF:FF:FF:FF:FF is broadcast to everything on the segment. None of these are devices, so none of them have a manufacturer.

Why modern phones randomise their MAC address

A MAC address used to be a permanent serial number that your phone shouted at every Wi-Fi network in range, whether or not you connected. Shopping centres, airports and advertising companies built a real industry out of logging those probes to follow individuals between visits and between venues. The address was never designed to be a tracking identifier, but it made an excellent one: stable, unique, and impossible to clear like a cookie.

Every major platform now defeats that. iOS, Android, Windows and recent Linux desktops generate a random address — a different one per network, often rotated on a timer — and set the U/L bit to declare it locally administered. Looking one up is meant to return nothing, and this tool says so plainly instead of implying its database is incomplete.

Two practical consequences. First, MAC filtering on a home router is now even less useful than it already was: the address is self-reported, trivially changed, and no longer stable. Second, if you rely on MAC addresses for DHCP reservations or network access control, turn randomisation off for that specific network on the devices concerned — every platform offers a per-network switch, precisely because this trade-off exists.

How this lookup works

It is an offline database lookup. IPGet keeps a local copy of the three IEEE registry files — 39,941 MA-L blocks, 6,548 MA-M and 7,133 MA-S — and answers from memory. Nothing is fetched from the IEEE, from a vendor API, or from anywhere else at the moment you press the button, so no third party learns which address you asked about.

The lookup runs on the server rather than in your browser for one reason: the registry files are roughly 1.8 MB, and downloading all of them to answer a single question would be absurd. Your browser sends the address, the server parses it, checks three tables and returns the result. The address is not logged or stored; see the privacy policy.

Because the registry is a snapshot, a very recently assigned block may not be present yet. When that happens you get an empty answer rather than an approximate one — the same rule the rest of IPGet follows. A value we cannot determine is reported as unknown, never invented.