How to Generate a MAC Address (and Why the Two Bits in the First Octet Decide Everything)

The problem: 48 bits, two of which are reserved for meaning

A MAC address is a 48-bit identifier burned into a network interface at the factory. It is written as six hex octets, usually colon-separated: 00:1A:2B:3C:4D:5E. The first three octets (24 bits) are the Organizationally Unique Identifier, or OUI, which the IEEE Registration Authority assigns to a vendor. Apple has many OUIs, Cisco has many, Intel has many. The last three octets (24 bits) are the device-specific portion, which the vendor assigns to each NIC it manufactures. The combination is supposed to be globally unique — no two NICs in the world should share the same 48-bit address.

Two bits in the first octet are not part of the OUI identity. They are reserved for meaning. Bit 0 (the least significant bit of the first octet) says whether the address is unicast (bit 0 = 0) or multicast (bit 0 = 1). Bit 1 says whether the address is universally administered (bit 1 = 0, meaning the OUI was assigned by the IEEE) or locally administered (bit 1 = 1, meaning someone other than the IEEE-assigned owner set this address). These two bits are why a MAC generator has any decisions to make at all. A generator that picks six random bytes without setting these bits produces an address that is technically valid hex but semantically wrong — it will claim to be universally administered by a vendor whose OUI it does not own.

The MAC Address Generator handles these bits correctly. It lets you choose unicast or multicast, universally or locally administered, and sets or clears the bits in the first octet accordingly. Knowing why those choices matter is the skill.

Fastest path

Open the MAC Address Generator. Pick an address type: unicast (default, for a single interface) or multicast (for a group destination). Pick an administration type: universally administered (default, but usually wrong for generated addresses) or locally administered (usually right). Optionally pick a vendor OUI from the dropdown or type a custom one. Pick a format: colon, hyphen, no separator, or Cisco dotted. Set the count (1 to 100, default 5). Click Generate. Each result has a copy button. Click Copy All for the full list.

The 48-bit structure, and which bits are which

The MAC address is six octets. The first three are the OUI. The last three are the device-specific portion, sometimes called the NIC specific part or the extension identifier. The IEEE assigns OUIs in blocks, and vendors assign the device portion within each block. With 24 bits of device space, a single OUI gives the vendor 16,777,216 addresses, which is why big vendors hold multiple OUIs.

The two reserved bits live in the first octet, at the two least significant positions. Bit 0 is the Individual/Group bit: 0 for unicast (an individual interface), 1 for multicast (a group of interfaces). Bit 1 is the Universal/Local bit: 0 for universally administered (the OUI was assigned by the IEEE), 1 for locally administered (you set this address yourself, and it does not claim IEEE ownership).

When a generator picks a fully random first octet, both bits are random. The generator then overwrites them based on your selection. For unicast, it clears bit 0 with firstByte & 0xFE. For multicast, it sets bit 0 with firstByte | 0x01. For universally administered, it clears bit 1 with firstByte & 0xFD. For locally administered, it sets bit 1 with firstByte | 0x02. The other six bits of the first octet are left as the random value, which is the part that identifies the (fake) OUI.

Why locally administered is usually the right choice

A generated MAC address is not assigned by the IEEE to a vendor you work for. If you set the U/L bit to 0 (universally administered), you are claiming that the first three octets are an OUI owned by someone who paid the IEEE for it. If those three octets happen to collide with a real vendor's OUI, you are impersonating that vendor on your local network, which can cause real problems — switches may learn the wrong MAC-to-port mapping, ARP tables may get confused, and if the real vendor's equipment is on the same network, you get a duplicate MAC situation.

Setting the U/L bit to 1 (locally administered) tells every device on the network that this address is locally assigned and does not claim IEEE ownership. The address space for locally administered addresses is 2 to the 46th power, because the two reserved bits are fixed and 46 bits are free. That is a huge space, and the only constraint is that you should not collide with other locally administered addresses on the same network.

Locally administered addresses are what virtualization platforms use. VMware uses 00:50:56 and 00:0C:29 for some of its ranges, but the manually-assigned range is 00:50:56:00:00:00 to 00:50:56:3F:FF:FF, which is locally administered by convention. Hyper-V uses 00:15:5D. VirtualBox uses 08:00:27. KVM and QEMU use 52:54:00 with the locally-administered bit set (note 52 has bit 1 set: 0x52 = 01010010, bit 1 is 1). Docker bridge containers use 02:42 followed by the container's IP-derived bytes, and 02 has bit 1 set (0x02 = 00000010), so the locally-administered bit is set. Privacy MACs in iOS and Android, which randomize per network to prevent tracking, also set the locally-administered bit.

If you are generating MACs for testing, for virtual interfaces, for Docker containers, or for anything that is not a physical IEEE-assigned NIC, use locally administered. Use universally administered only if you have a real OUI you own and you are generating device portions for it.

Why the randomness source matters

The device portion is 24 bits, which is 16,777,216 possible values. If you are generating MACs for a virtualization cluster with thousands of VMs, or for a test suite that runs millions of generations, the chance of a collision within the device portion becomes real. The birthday paradox says that with a 24-bit space, you have a 50% chance of a collision after about 4,900 randomly generated values, and a near-certain collision after 16,000.

The MAC Address Generator uses crypto.getRandomValues, the Web Crypto API's cryptographically secure random number generator. This is the right choice. It produces uniformly distributed bytes that are not predictable and that do not collide in any practical sense within the 24-bit device space. A generator using Math.random would be wrong for two reasons: Math.random is not cryptographically secure (its output is predictable if you know the seed), and Math.random typically has a 128-bit internal state but produces floating-point outputs that do not evenly cover the 24-bit integer space, which means some device portions are slightly more likely than others, which makes collisions slightly more likely than the birthday-paradox math suggests.

For MAC generation, the security property of crypto random is not the point (you are not protecting a secret). The uniformity property is the point. crypto.getRandomValues produces bytes that are uniform across the 256 values per octet, which is what you want for the device portion.

The four formats, and when each is used

The four formats are cosmetic transformations of the same 48-bit value. Which one you use depends on which tool or context expects the input.

Colon-separated (AA:BB:CC:DD:EE:FF) is the canonical form. Most documentation, most configuration files, and most CLI tools (ifconfig, ip, netsh) accept this format. Use it by default.

Hyphen-separated (AA-BB-CC-DD-EE-FF) is common in Windows. The netsh interface and some Windows tools accept or prefer hyphens. It is the same value, just with a different separator.

No separator (AABBCCDDEEFF) is used when you need to pass the MAC as a single token, without separators. Some configuration files, some scripts, and some databases store MACs this way. It is harder to read but easier to grep.

Cisco dotted (AABB.CCDD.EEFF) is the format Cisco routers and switches use in their configuration and show output. It is also used in ARP table displays on Cisco equipment. If you are configuring a Cisco device, this is the format the CLI expects for MAC access-control lists and for static MAC entries. The format splits the 12 hex digits into three groups of four, separated by dots.

How vendor OUI prefixes interact with the bit override

The MAC Address Generator has a dropdown of about two dozen vendor OUIs: Apple, Intel, Cisco, Samsung, Google, Amazon, Microsoft, VMware, Dell, HP, Lenovo, Broadcom, Qualcomm, Huawei, Xiaomi, Nintendo, Sony, LG, Oracle. Selecting one populates the custom OUI field with the first three octets. The last three octets are generated randomly.

The catch is that the generator still applies the bit override to the first byte of the vendor OUI. If you select Apple's OUI 00:1A:2B and choose locally administered, the generator sets bit 1 of 00, turning it into 02. The output starts with 02:1A:2B, not 00:1A:2B. The vendor's original U/L bit (which was 0, universally administered) is overwritten with your selection.

This is the correct behavior if you want a locally administered address that starts with a vendor's OUI for identification purposes. It is wrong if you want to preserve the vendor's exact OUI, because the first octet is modified. There is no toggle to disable the bit override when a vendor OUI is selected. If you need the exact vendor OUI preserved with universally administered bits, choose "universally administered" (which clears bit 1, leaving 00 unchanged) and select the vendor.

Gotchas

• The vendor OUI list is tiny. The dropdown has about two dozen entries. The full IEEE OUI registry has over 30,000 assigned OUIs. The generator does not include the full registry, and there is no way to look up an arbitrary OUI in the generator. For the full registry, use the MAC Address Lookup tool, which resolves an OUI to a vendor name.
• The bit override applies even when a vendor OUI is selected. Selecting Apple and locally administered turns 00:1A:2B into 02:1A:2B. The first octet is modified. If you want the vendor OUI preserved exactly, choose universally administered.
• Custom OUI parsing is lenient. The custom OUI field strips colons and hyphens, then takes the first three hex pairs. It does not validate that the input is valid hex. Typing ZZ:ZZ:ZZ produces NaN:NaN:NaN in the output, because parseInt('ZZ', 16) returns NaN. There is no error message.
• No lowercase toggle. Output is always uppercase hex. If you need lowercase (some tools prefer lowercase MACs), you have to lowercase the output yourself.
• No download despite the FAQ claim. The FAQ says "you can then copy the result to your clipboard or download it," but there is no download button in the component. You can copy individual MACs or copy all to the clipboard, but you cannot download a file. If you need a file, paste the clipboard contents into a text editor and save.
• No EUI-64. The generator produces only 48-bit MACs (EUI-48). It does not produce 64-bit EUI-64 addresses, which are used in IPv6 stateless autoconfiguration. An EUI-64 is derived from a 48-bit MAC by inserting FF:FE between the OUI and the device portion and flipping the U/L bit. The generator does not do this. If you need an EUI-64, you have to derive it manually.
• No validation that an OUI is actually assigned. If you type a custom OUI that the IEEE has not assigned to anyone, the generator accepts it and produces addresses with it. The generator does not check the IEEE registry.
• No persistence. Generated MACs live in React state. Refreshing the page or navigating away loses them. If you need to keep them, copy or copy-all before navigating.
• No reproducibility. The generator uses crypto.getRandomValues, which is not seedable. Clicking Generate twice produces different MACs. If you need a reproducible batch, you have to save the output and reuse it.
• The badges are computed from the actual bits. Each generated MAC displays a Unicast/Multicast badge and a Local/Universal badge. These are computed at render time from the actual bits in the generated address, not from your selections. This is a verification feature: if the badge does not match your selection, something went wrong. In practice it always matches, because the bit override is applied before display.
• Multicast is rarely what you want. Multicast MACs are for group destinations, not for individual interfaces. The first octet of a multicast MAC has bit 0 set, which makes the address a group destination in Ethernet. If you are generating a MAC for a virtual interface, a VM, a container, or a test fixture, use unicast. Use multicast only if you are configuring a multicast group destination.
• The count clamps silently. The input allows 1 to 100. Typing 500 and clicking Generate produces 100, with no warning. If you need more, run the generator multiple times.

Summary

• A MAC address is 48 bits: a 24-bit OUI assigned by the IEEE to a vendor, and a 24-bit device portion assigned by the vendor. Two bits in the first octet are reserved for meaning, not identity: bit 0 is unicast/multicast, bit 1 is locally/universally administered. A generator that ignores these bits produces addresses that look valid but are semantically wrong.
• Locally administered is usually the right choice for generated MACs, because you are not a vendor with an IEEE-assigned OUI. Setting the U/L bit to 1 claims local administration, which is what virtualization platforms (VMware, Hyper-V, VirtualBox, KVM), container runtimes (Docker's 02:42), and privacy MACs in iOS and Android all do. Use universally administered only if you own the OUI.
• The randomness source matters. The 24-bit device portion is small enough that Math.random collides within a few thousand outputs. crypto.getRandomValues is uniform and does not collide in any practical sense. The MAC Address Generator uses crypto random, which is the right choice for the device portion.
• The four formats (colon, hyphen, no separator, Cisco dotted) are cosmetic. Use colon by default, hyphen for Windows, no separator for scripts and databases, and Cisco dotted for Cisco router and switch configuration. Use the MAC Address Lookup to resolve an OUI to a vendor, the IP Info Lookup to inspect an IP address, and the Subnet Calculator for IP subnet math.