The two flag bits in the first byte
A MAC address is 48 bits, and two bits of its first byte have fixed meanings. The lowest is the individual/group bit: 0 for a unicast address that belongs to one interface, 1 for a multicast address that names a group. The bit next to it is the universal/local bit: 0 for an address issued from a manufacturer's IEEE-assigned block, 1 for one chosen locally.
Without a prefix, the generator draws six random bytes and then forces those two bits to match the checkboxes. The other 46 bits stay random. Because the flags sit in the low half of the first byte, you can read them from the second hex digit of any address in the list.
- Locally administered on, Multicast off (the default): second digit 2, 6, A or E.
- Both off: second digit 0, 4, 8 or C, the range that real vendor blocks occupy.
- Multicast on: an odd second digit, which no interface accepts as its own address.
Working with a fixed prefix
The Fixed prefix / OUI field accepts one to five whole bytes of hex, with or without colons, hyphens or dots. Those bytes are copied to the front of every address and the rest is random. Three bytes is the usual choice, since that is the length of a vendor OUI: 52:54:00 keeps addresses in the block that QEMU and KVM use for guests.
The tool does not second-guess what you type. If the first byte is odd, every address is multicast. If the prefix comes from a registered vendor block, the addresses look like that vendor's hardware in any inventory or OUI lookup. An odd number of hex digits, or more than five bytes, shows an error asking for one to five bytes of hex.
For addresses that will appear in manuals or screenshots, RFC 7042 set aside 00:00:5E:00:53:00 to 00:00:5E:00:53:FF for documentation. Enter 00:00:5E:00:53 as the prefix and only the last byte varies. That leaves 256 possible values, so a large batch repeats some of them.
Where generated addresses are used
Virtual machines and containers are the common case. A hypervisor normally assigns addresses itself, but cloned guests, hand-written machine definitions and static DHCP reservations all need addresses you choose. Taking them from the locally administered range keeps them clear of the burned-in address of any physical card that later joins the same network.
The second use is test data. DHCP servers, network access control, asset inventories and log parsers all need realistic MAC addresses in their fixtures, and copying real ones from production leaks device information. To check what an existing prefix belongs to before you reuse it, MAC address lookup returns the registered manufacturer.
What a duplicate or wrong address does
Uniqueness matters only inside one layer 2 segment, but there it matters completely. If two interfaces on the same VLAN share an address, the switch keeps moving that address between two ports, frames reach whichever host spoke last, and both suffer intermittent loss that is tedious to trace. Cloned virtual machines that kept the template's address are the usual culprit.
A multicast address on an interface fails sooner: operating systems reject it, because a source address must be unicast. An address from a real vendor's block works, but it misleads whoever reads the ARP table later. Changing an interface's address also changes its DHCP identity, so expect a new lease afterwards.
Randomness and limits
The bytes come from crypto.getRandomValues, the browser's cryptographic random source, after the page has loaded. Nothing is requested from or sent to a server, and the list is not saved: a reload replaces it. Each batch holds at most 100 addresses, so click Regenerate and copy again when you need more.
Random is not the same as managed. The generator has no memory of earlier batches, so if you hand addresses to many machines, record each one alongside your IP plan and check new batches against that record before using them on the same segment.