A MAC address is the 48-bit hardware identifier carried by every network interface, written as six hexadecimal octets. This generator produces correctly formatted random MAC addresses with the separator, case, and control-bit options you need for network testing, mock device inventories, and configuration scripts.
How it works
Six random octets are generated, then the first octet is adjusted to set the two control bits correctly:
first octet bit 0 (0x01) = I/G bit : 0 = unicast, 1 = multicast
first octet bit 1 (0x02) = U/L bit : 0 = universal (OUI), 1 = locally administered
When you ask for a locally-administered address the tool ORs 0x02 into the first octet so
the U/L bit is set; for a universal address it clears that bit. Likewise the I/G bit is set
or cleared for multicast or unicast. The six octets are then joined using your chosen
separator and case.
Understanding the first octet: why those two bits matter
Every MAC address carries two flags in the first octet that affect how switches and routers interpret the address:
The I/G bit (bit 0): Determines whether the frame goes to a single device (unicast, bit = 0) or a group of devices (multicast, bit = 1). Nearly all device addresses are unicast. Multicast MAC addresses are used by protocols like IPv6 neighbor discovery and certain streaming technologies. Generating a multicast address for a test is valid — just be aware that switches handle multicast frames differently from unicast.
The U/L bit (bit 1): Marks whether the address was assigned by the IEEE to a hardware vendor (universal, bit = 0) or was manually assigned locally (locally administered, bit = 1). Random test addresses should always set this bit — it guarantees the address can never match a real OUI-registered device, preventing accidental address collisions on a real network.
A locally-administered unicast address has the first octet looking like: xE in hex (for any
nibble x where the second nibble’s bit pattern has 0x02 set and 0x01 clear). Common
examples: 02:xx:xx:xx:xx:xx, 06:xx:xx:xx:xx:xx, 0A:xx:xx:xx:xx:xx.
Platform-specific formats
| Platform | Format | Example |
|---|---|---|
| Linux / macOS | Colon-separated, lowercase | aa:bb:cc:dd:ee:ff |
| Windows (ipconfig) | Hyphen-separated, uppercase | AA-BB-CC-DD-EE-FF |
| Cisco IOS | Dotted triplets, lowercase | aabb.ccdd.eeff |
| Some APIs / databases | No separator | aabbccddeeff |
Cisco’s dotted format splits the 48 bits into three 16-bit groups rather than six 8-bit octets, which changes the visual grouping. It still represents the same address — just be careful not to confuse the grouping when converting between formats.
Common testing scenarios
- Network configuration scripts: generate a batch of locally-administered unicast addresses to assign to virtual machines or containers in a test environment.
- Mock device inventories: populate a database with realistic-looking but non-real MAC addresses for software testing without using real hardware identifiers.
- Switch and VLAN testing: test MAC flooding, port security, or VLAN tagging logic with known-fake addresses that won’t affect a production network.
- Wi-Fi privacy testing: generate addresses to test randomized MAC address handling in access point logs.
Tips and notes
For throwaway test addresses, keep the locally-administered bit on so they live in the private range and can never collide with a real vendor-assigned address. Match the separator to your platform — colons for Linux and macOS, hyphens for Windows, dotted triplets for Cisco IOS. If you need a deterministic set for repeatable tests, generate once and store the list rather than regenerating, since each batch is random. Everything runs in your browser; nothing is sent to a server.