MAC Address Generator_
Six random bytes is not a random MAC address. The first octet carries two flags, and getting them wrong produces an address that either belongs to a real manufacturer's assigned block or is not an interface address at all — which is what most generators hand you.
Every address here has the locally-administered bit set and the multicast bit clear, which is exactly what an operating system does when it randomises a MAC for privacy. The checker underneath will tell you which kind any address you already have turns out to be.
- Input
- A count, a format, and optionally a vendor prefix when you need addresses that look like they came from a particular hypervisor.
- Output
- Addresses in colons, hyphens, Cisco dot notation or with no separator, upper or lower case. All distinct within a batch.
- Processing
- Generated in this tab from crypto.getRandomValues — the browser's cryptographic random source, not Math.random.
- Limits
- Up to 500 at a time. This generates addresses; it cannot tell you whether one is already in use on your network, because nothing outside your network can.
- The two bits in the first octet
- Bit 1 is the U/L flag: set means locally administered, so nobody owns it globally. Clear means the first three octets are an OUI that IEEE assigned to a specific manufacturer. Bit 0 is the I/G flag: set means multicast, which is a group address rather than an interface. A generator emitting six random bytes gets the first wrong three quarters of the time and the second wrong half the time.
Why six random bytes is the wrong answer
What the first octet is actually for
A MAC address is 48 bits written as six octets, and the first octet is not just the start of the number. Its lowest two bits are flags. Bit 1 — the U/L flag — says whether the address is universally or locally administered: universally means IEEE assigned the first three octets to a named manufacturer as an Organisationally Unique Identifier, and locally means nobody owns it and you are free to make it up. Bit 0 — the I/G flag — says whether the address identifies one interface or a group. Both flags live in the byte a naive generator randomises without looking.
What a naive generator produces
Emit six random bytes and, on average, half of them have the multicast bit set — addresses that are not interface identifiers at all and which most operating systems will refuse to accept. Of those that are unicast, three quarters have the U/L bit clear, which means the first three octets land somewhere in the space IEEE has allocated to real companies. It is not a collision in any practical sense, and it is still an address claiming to be from a vendor's block when it is not. Setting one bit fixes both problems.
This is what MAC randomisation already does
Every current phone and laptop randomises its MAC address when scanning for Wi-Fi networks, and increasingly per network it joins, so that a device cannot be tracked across locations by its hardware address. Those randomised addresses are locally administered — that is the whole convention — which is why an address starting 02, 06, 0A or 0E in a network log is very likely a privacy-randomised client rather than an unknown vendor.
Reading a MAC you found in a log
The first three octets identify the manufacturer when the U/L bit is clear, and a handful are worth recognising by sight because they turn up constantly: 00:50:56 and 00:0C:29 are VMware, 08:00:27 is VirtualBox, 00:15:5D is Hyper-V, and 52:54:00 is QEMU and libvirt — that last one is itself locally administered, which is why it looks different from the others. For anything else, the IEEE registry is the authority and it changes weekly, so a lookup is worth more than a list.
Changing a real machine's MAC
It is a normal administrative operation — ip link set dev eth0 address … on Linux, an adapter property on Windows, and a per-network setting on phones — and the usual reasons are legitimate: testing DHCP reservations, replacing a failed card without reconfiguring a network, or avoiding being tracked on public Wi-Fi. Use a locally administered address when you do it, and expect anything that authenticates by MAC to stop recognising the machine, because that is precisely what you changed.
Generate, or check what you already have
- 01Choose how many and which format. Colons are the common convention; Cisco equipment writes them as three dot-separated groups.
- 02Leave "locally administered" on unless you specifically want an address inside a vendor block — the warning above says what turning it off means.
- 03Pick a vendor prefix if you need addresses that look like they came from a particular hypervisor. The prefix is kept exactly as its owner defined it, flags included.
- 04Paste any address into the checker to see whether it is locally administered, whether it is even an interface address, and what its OUI is.
Test data for a device inventory
Seeding a database or a test fixture with addresses that are structurally valid and cannot collide with real hardware anywhere in the world.
a1:b2:c3:d4:e5:f6 // multicast bit clear by luck, // U/L bit clear — inside a real OUI
02:b2:c3:d4:e5:f6 // locally administered, unicast, // owned by nobody
A virtual machine that should look like one
Sometimes you want the hypervisor prefix preserved — for a lab that mirrors production, or to test software that identifies guests by their OUI.
VMware · 00:50:56
00:50:56:3a:7f:c1 Prefix untouched, tail random.
An address in a log you cannot place
Not in any vendor database, and it changes between sessions. The first octet answers it immediately.
0a:4c:19:88:2e:7b
Locally administered · unicast Almost certainly a phone or laptop randomising its MAC for privacy.
An address that will never be accepted
The multicast bit is set, so this is a group address. Assigning it to an interface is not a configuration mistake so much as a category error.
01:00:5e:00:00:01
Multicast — a group address. Not an interface identifier at all.
What the first octet tells you
| First octet ends in | U/L | I/G | Meaning |
|---|---|---|---|
0, 4, 8, C | Universal | Unicast | A real interface address inside an IEEE-assigned vendor block. Almost all physical hardware. |
2, 6, A, E | Local | Unicast | A locally administered interface address. Randomised phones, hypervisor guests, and anything set by hand — including everything this page generates. |
1, 5, 9, D | Universal | Multicast | A group address. Never an interface. 01:00:5E is IPv4 multicast, 33:33 is IPv6. |
3, 7, B, F | Local | Multicast | A locally scoped group address. Rare, and never something to assign to a card. |
FF:FF:FF:FF:FF:FF | — | Broadcast | Every device on the segment. |
00:00:00:00:00:00 | — | — | The null address — a placeholder, not an identifier. |
Reading the last hexadecimal digit of the first octet is the whole trick, and it is why an address starting 02 tells you more about its origin than the other five octets combined.
Working with MAC addresses
- Use a locally administered address whenever you invent one. It costs nothing, and it guarantees no manufacturer ever ships hardware carrying the same number.
- Do not treat a MAC as a security boundary. It is sent in the clear in every frame and can be changed in one command, which is why MAC filtering is a convenience rather than access control.
- Expect randomised addresses on modern Wi-Fi. A device that appears under a new address on each visit is behaving correctly, and inventory built on MAC identity will drift.
- Look prefixes up rather than memorising them. The IEEE registry has tens of thousands of entries and changes weekly; only the hypervisor ones are worth knowing by sight.
- Keep DHCP reservations keyed on something else where you can. Anything that identifies a device by MAC breaks the moment the card is replaced or the address is randomised.
Where MAC addresses are misunderstood
A random 48-bit number is not a valid random MAC
Half of them are multicast and most of the rest sit inside a real vendor block. Both are fixed by forcing one bit, and almost no generator does it.
MAC filtering is not access control
Addresses travel unencrypted in every frame on the network, so anyone who can see the traffic can see the allowed list and copy an entry. It keeps honest devices off; it stops nobody else.
A MAC does not cross a router
It identifies an interface on one network segment. Anything beyond the first router sees only the IP address, which is why MAC-based identification only ever works locally.
Uniqueness is a promise, not a guarantee
Universally administered addresses are meant to be globally unique, and duplicates have shipped from manufacturers more than once. Locally administered ones make no such claim at all — which is the honest position for an address you generated.
Structure, flags and randomness
- Structure
- 48 bits as six octets. The first three are the OUI when the address is universally administered; the last three identify the interface within that block.
- U/L flag
- Bit 1 of the first octet. Set for locally administered — forced on for every address generated here unless a vendor prefix is chosen, in which case the prefix owner's flags are preserved.
- I/G flag
- Bit 0 of the first octet. Cleared on every generated address, because a multicast address is a group rather than an interface.
- Randomness
- crypto.getRandomValues. Not Math.random, which is not required to be unpredictable and is the wrong source even for test data.
- Formats
- Colon-separated, hyphen-separated, Cisco three-group dot notation, and unseparated. All four parse back to the same six octets, which the test suite asserts.
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Questions about MAC addresses
What makes a generated MAC address valid?
Two bits in the first octet. The locally-administered bit must be set, so the address is not claiming space IEEE assigned to a manufacturer, and the multicast bit must be clear, because a multicast address identifies a group rather than an interface. Six random bytes satisfies neither reliably.
What is a locally administered MAC address?
One where bit 1 of the first octet is set, meaning no organisation owns it globally and you are free to assign it yourself. In practice you see them as addresses whose first octet ends in 2, 6, A or E. Every phone randomising its Wi-Fi address uses one, and so does everything generated here.
Can I change my device's MAC address?
Yes, and it is an ordinary administrative operation — ip link set on Linux, an adapter property on Windows, a per-network setting on phones. Use a locally administered address, and expect anything that authenticates or reserves by MAC to stop recognising the device, since that is exactly what changed.
What are the first six characters of a MAC address?
The Organisationally Unique Identifier, when the address is universally administered — three octets IEEE assigned to a specific manufacturer. On a locally administered address they mean nothing at all, because nobody assigned them.
Why do all my virtual machines have similar MAC addresses?
Because hypervisors generate within their own registered prefix. 00:50:56 and 00:0C:29 are VMware, 08:00:27 is VirtualBox, 00:15:5D is Hyper-V, and 52:54:00 is QEMU and libvirt. Recognising them is often the quickest way to tell a guest from a physical machine in a log.
Is MAC filtering good security?
No. Addresses are transmitted unencrypted in every frame, so anyone able to observe the network can read the permitted list and clone an entry in one command. It is a convenience for keeping unconfigured devices off a network, not a control that resists anyone trying.
Can two devices have the same MAC address?
They should not, and it happens. Universal uniqueness depends on manufacturers using their allocation correctly, and duplicates have shipped. On one segment a collision causes intermittent, confusing faults; across a router it is invisible, because MAC addresses do not travel that far.
Why does my phone show a different MAC on every network?
Privacy randomisation, and it is deliberate. A fixed hardware address lets any network you join track you across locations, so modern phones present a different locally administered address per network. Inventory systems that identify devices by MAC will see them as new devices each time.
Are the addresses generated here sent anywhere?
No. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.