What is a random MAC address, and is this one usable as-is?
A MAC address is the 48-bit hardware address an Ethernet or Wi-Fi interface uses on the local network, written as 12 hex digits in six pairs. This generator fills the address with random bits, then fixes the two flag bits in the first byte so the result is always a unicast, locally administered address. It prints them in lowercase, colon-separated, and every one is ready to assign to a virtual machine, container or test interface without editing.
The same output works for test fixtures, log samples and form validation, where any well-formed address will do.
The two bits in the first byte
The lowest two bits of the first byte change what kind of address it is. RFC 9542, which documents IEEE 802 parameters for IETF use, describes them:
- I/G (Individual/Group), value 0x01. Zero means unicast, an address for one interface. One means group or multicast.
- U/L (Universal/Local), value 0x02. Zero means a globally unique address under the control of whoever owns the IEEE-assigned prefix, the vendor. One means locally administered, set by you.
The generator clears I/G and sets U/L. In code that's one expression on the first byte, (b & 0xfc) | 0x02. Both bits sit in the second hex digit you see, so you can read any address's type at a glance:
| Second hex digit | Unicast or multicast | Universal or local | Produced by this tool? |
|---|---|---|---|
| 0, 4, 8, c | Unicast | Universal (vendor space) | No |
| 1, 5, 9, d | Multicast | Universal | No |
| 2, 6, a, e | Unicast | Local | Yes, always |
| 3, 7, b, f | Multicast | Local | No |
A sample run gave 3a:57:b9:3a:3c:fb, 0e:71:67:f8:0e:3f and 9a:bd:e3:5d:4d:7b. The second digits are a, e and a, so all three are locally administered unicast.
Why does it matter? A multicast address isn't valid as an interface's own address, and on Linux ip link set ... address rejects one. A universal-looking address is legal but sits in space that belongs to hardware vendors, so a clash with a real card, however unlikely, would be possible. Local addresses exist precisely so administrators can make up their own.
Generating addresses
- Set the Addresses slider (1 to 50).
- Click Generate. You get one address per line.
- Click Copy and paste them into your VM, container or test configuration.
Because the first byte's flag bits are fixed, the generator can't produce vendor-style addresses. If you specifically need an address that looks like real hardware, for example to test how your software handles a particular manufacturer's prefix, edit the first three bytes by hand.
Formats you'll run into
The bytes are the same everywhere; only the punctuation differs.
| Style | Example | Common in |
|---|---|---|
| Colon, lowercase | 3a:57:b9:3a:3c:fb | Linux, macOS, this tool |
| Hyphen, uppercase | 3A-57-B9-3A-3C-FB | Windows, IEEE documents |
| Dotted groups of four | 3a57.b93a.3cfb | Some network switch consoles |
A validator that accepts only one style will reject the others, so it's worth generating a batch and converting a few by hand to test all three.
Addresses for documentation
For manuals and examples, RFC 9542 sets aside a block that will never be assigned to hardware: 00-00-5E-00-53-00 through 00-00-5E-00-53-FF for unicast. Using those in docs avoids accidentally publishing an address that belongs to someone's device.
How random is it?
Each of the six bytes is drawn independently from crypto.getRandomValues(), and only the two flag bits are then fixed, which leaves 2^46 (about 70 trillion) equally likely addresses. Collisions between generated addresses on one network are not a practical worry. Generation happens entirely in the browser.
Related generators
Building out a test network? The random IP address generator produces IPv4 and IPv6 addresses to pair with these. For raw random bytes in other lengths, try the random hex generator or the random byte generator, and if you need identifiers rather than hardware addresses, the UUID generator makes random version 4 UUIDs.
Last updated