Network Tools

MAC Lookup

Look up vendor information for MAC addresses.

Supported formats:AA:BB:CC:DD:EE:FFAA-BB-CC-DD-EE-FFAABB.CCDD.EEFFAABBCCDDEEFF
📇

Enter a MAC address to look up the vendor

What is MAC Address Lookup?

MAC address lookup identifies the manufacturer of a network device from its MAC address (OUI - Organizationally Unique Identifier).

MAC Address Format

  • 6 bytes (48 bits)
  • Format: XX:XX:XX:XX:XX:XX
  • First 3 bytes: Manufacturer ID

Use Cases

  • Device identification
  • Network inventory
  • Security auditing

Resolves the 24-bit OUI prefix of a 48-bit MAC address to the organization that registered it, using a bundled table of a few hundred common vendors with a live vendor-lookup fallback. Input accepts colon, hyphen, dotted or bare notation, and the output adds unicast/multicast and universal/local bit flags so you can judge whether the vendor name applies at all.

One hex digit controls both flag bits

Bit 0 of the first octet is the I/G bit (0 unicast, 1 multicast) and bit 1 is the U/L bit (0 universally administered, 1 locally administered), so the last hex digit of the first octet alone decides both labels. Even digits 2, 6, A and E give a unicast address; digits 0, 1, 4, 5, 8, 9, C and D report as universal, the other eight as local. IEEE 802 sends each octet least-significant bit first, which is why the flags sit in the low bits rather than the high ones. Hence B8:27:EB:12:34:56 ends in 8 and reads as unicast plus universal, worth an OUI lookup, while FF:FF:FF:FF:FF:FF ends in F and reads as multicast plus local, even though it is the Ethernet broadcast address.

Two-tier vendor resolution and its cost

Vendor names come from two tiers. The component first checks a bundled map keyed by uppercase three-octet strings such as B8:27:EB, covering several hundred popular OUIs, then requests https://api.macvendors.com/<OUI> and replaces the local answer with the plain-text body only when the response is a success, non-empty, and free of the text Not Found. Network failures are caught and ignored, so a blocked request degrades silently to table-only results. Two consequences follow: an unknown-vendor result may mean the request failed rather than that the prefix is unregistered, and the OUI is disclosed to a third-party server, although the last three octets never leave the browser. Results are not cached, so repeated lookups of the same address hit the network again.

Hypervisor prefixes are conventions, not registrations

Several virtualization prefixes in the bundled table are not IEEE assignments. 52:54:00 for QEMU/KVM and 0A:00:27 for VirtualBox host-only adapters start with octets 0x52 and 0x0A, whose second bit is set, so the tool reports them as locally administered next to the vendor name. By contrast 00:50:56 and 00:0C:29 are genuine VMware registrations and come back as universal. A cloned VM keeps whatever prefix the image was built with, so a screen of identical addresses proves nothing about the hardware. Note also that only 24 bits are matched: MA-M (28-bit) and MA-S (36-bit) blocks that subdivide a shared prefix cannot be told apart, so two owners may look identical here.

Worked example

A Raspberry Pi address typed in Windows hyphen notation

Input
b8-27-eb-12-34-56
Output
MAC: B8:27:EB:12:34:56 | OUI: B8:27:EB | Vendor: Raspberry Pi Foundation | Type: Unicast | Admin: Universally administered

Validation strips every non-hex character first, so the lowercase hyphenated input collapses to 12 hex digits and is re-emitted as the canonical colon form; the OUI is the first 8 characters of that string. First octet 0xB8 has both low bits clear, giving unicast and universal. The bundled table already maps B8:27:EB to Raspberry Pi Foundation, so the answer is identical offline and the live service returns the same name online.

Limits and pitfalls

  • Exactly 12 hex digits are accepted: a 64-bit EUI-64 address, or a MAC with a trailing VLAN tag such as 00:1A:2B:3C:4D:5E:FF, fails with the invalid-format error.
  • Non-hex characters are deleted rather than rejected, so 00:1A:2B:3C:4D:5Z shrinks to 11 digits and reports the same invalid-format message, which never points at the real typo.
  • FF:FF:FF:FF:FF:FF, 33:33:xx:xx:xx:xx and other group addresses have no IEEE registrant, so any vendor text shown for them is noise.
  • When the U/L bit is set, the address is locally administered, which is normal for randomized Wi-Fi MACs and hypervisor conventions; no registry entry can confirm a manufacturer.
  • Offline or rate-limited lookups fall back to the bundled table without saying so, so an unknown-vendor answer is not evidence that the prefix is unregistered.

Related tools

When it goes wrong

I pressed Search and the spinner ran for a minute without an answer, so I reloaded the page.

CauseThe handler sets loading true and passes https://api.macvendors.com/<OUI> to await fetch(), then clears the flag only once that promise settles. There is no AbortController, no timer and no finally guard, so a connection that hangs instead of failing keeps the spinner up indefinitely; the catch branch only handles requests that throw.

FixOpen the Network panel, find the pending api.macvendors.com entry, right-click it and choose Block request URL, then press Search again. A blocked request rejects immediately, the silent catch fires and the bundled-table result renders.

One address showed a vendor name this morning and reads unknown vendor tonight, same digits.

CauseThe vendor text has two sources with different spellings: the bundled map is hand-shortened (Apple, Dell, Intel), while the live service returns the registrant name as the registry writes it. Which one appears depends on whether that call succeeded this time — a rate-limited, blocked or rejected request is swallowed silently and the table value stands, and a prefix outside the few-hundred-entry table then renders as unknown vendor. Nothing is cached, so each search is a new request.

FixBlock api.macvendors.com when you need two searches to agree; the answer then comes from the bundled map every time. When the name has to be citable, look the first three octets up in the IEEE registry and quote that, not either string this page produced.

The dice button keeps giving me addresses marked locally administered, and the vendor is always unknown.

CauseThe generator rewrites the first octet with (firstByte | 0x02) & 0xFE: the U/L bit is forced to 1 and the I/G bit to 0, so local plus unicast is guaranteed. All six octets are random, so the first three practically never match the bundled table, and no registry holds a registrant for a prefix nobody was assigned.

FixRead that button as a source of disposable locally administered addresses for screenshots and test fixtures. To identify real hardware, take the address from ipconfig /all, ifconfig or the router DHCP client list and paste that instead.

I switched the page to Chinese and the vendor name from my earlier search is still English in the result card.

CauseThe vendor string is computed once inside the click handler and stored on macInfo.vendor. The surrounding labels re-render through the translation lookup, but this stored string is not recomputed when the locale changes; the unknown-vendor placeholder keeps the language it was generated in, and text returned by the live service arrives in English regardless of locale.

FixSwitch language first, then press Search again — the address stays in the box. If the name must be Chinese, resolve the OUI against a registry rather than reusing the card text.

I pasted lowercase and the result card shows uppercase, then the copy button output did not match the box either.

CauseThe uppercase look is a CSS text-transform on the input, which changes rendering only, not the bound value. The result card and the copied text both use normalizedMac, the uppercase colon form rebuilt by the cleaner, so three strings exist for one address: what you typed, what you see, and what you copy.

FixTreat the copy output as the canonical form when the string travels onward. Do not treat the input box as a record of the address, since it keeps whatever case and separators you pasted.

Which address spellings survive the cleaner, and which come back as a format error

What you pasteExampleOutcome
Canonical form, colon separated, uppercaseAA:BB:CC:DD:EE:FFAccepted; the MAC line echoes it back unchanged
Hyphen separated, as Windows lists adaptersaa-bb-cc-dd-ee-ffAccepted; hyphens dropped, output AA:BB:CC:DD:EE:FF
Cisco dotted tripletsAABB.CCDD.EEFFAccepted; dots dropped, same canonical output
Bare 12 hex digitsAABBCCDDEEFFAccepted; regrouped into six octets
Octets broken up by spacesAA BB CC DD EE FFAccepted; spaces dropped, 12 digits remain
C-style 0x prefixes copied out of code0xAA 0xBB 0xCC 0xDD 0xEE 0xFFRejected: 18 digits survive, because the 0 of every 0x is itself a hex digit and only the x is deleted
A label dragged in with the addressMAC: 00:1A:2B:3C:4D:5ERejected: A and C inside the word count as hex, giving 14 digits
EUI-64, eight octets20:11:22:FF:FE:33:44:55Rejected: 16 digits; only 48-bit addresses are accepted
Address plus a trailing VLAN tag byte00:1A:2B:3C:4D:5E:64Rejected: 14 digits; delete the last byte first
Five octets only00:1A:2B:3C:4DRejected: 10 digits

Every row follows one rule: everything outside 0-9A-Fa-f is deleted, then the remainder must be exactly 12 characters. Too few and too many digits raise the same format error, so the message never names the part that is wrong — count the digits before retyping.

Frequently Asked Questions

What can a MAC address prefix tell me?
The first 3 bytes (the OUI, Organizationally Unique Identifier) are assigned by the IEEE and identify the NIC vendor. This tool resolves prefixes against the public IEEE database and can search a vendor’s assignments — handy for "whose device is this on my LAN".
Is the listed vendor the device brand?
Not necessarily. The OUI identifies the chip or module maker: an ASUS router using a Broadcom reference design shows up as Broadcom. Treat OUI as a supply-chain lead, not a brand verdict.
Are MAC addresses a privacy concern?
This tool only needs the prefix. Related note: phones use "randomized MAC" per Wi-Fi network precisely to prevent tracking by address; for administration, find the real address in the phone’s settings.

Content reviewed: