MAC Address Generator

The U/L Bit — This Tool's Most Important Setting

A MAC address is 48 bits long. The first 3 bytes are the OUI (Organizationally Unique Identifier) which identifies the manufacturer, and the last 3 bytes are a serial number assigned by the manufacturer. If you just pick 6 random bytes, you might accidentally overlap with a real manufacturer's OUI. This isn't a problem you can ignore just because it's improbable — if a real device with that same MAC exists on your network, you'll experience intermittent connection drops that are notoriously difficult to debug.

This is why the specification has a built-in solution. By setting the second bit of the first octet (the U/L bit) to 1, the address becomes a "Locally Administered Address." The IEEE does not assign these ranges to manufacturers, which means they will never conflict with a real device. This is why "Locally Administered" is the default setting in this tool. If you're generating addresses for VMs, containers, or testing, you should leave it this way.

• Locally Administered Addresses (for unicast) have a first octet ending in x2, x6, xA, or xE. When you see a MAC like 02:1A:… or 4A:3B:…, you can read it as "this address was set manually."
• Choosing "Universal" creates a MAC in the manufacturer-assigned format, which can conflict with real devices. Only use this for tests where you need to mimic a specific manufacturer's OUI.
• Setting the I/G bit to "Multicast" creates a group address. It's not meant for individual devices and shouldn't be used as a NIC's MAC address.

Modern Phone MACs Change Constantly

Starting with iOS 14 and Android 10, a feature that uses a random MAC address instead of the real one when connecting to Wi-Fi is enabled by default. Furthermore, it uses a different address for each network (SSID) you connect to. This is a privacy measure to prevent devices from being tracked as they move between locations. All addresses generated this way have the Local Administered bit set — the very same bit described above.

This change has broken several common practices in the field.

• MAC-based visitor and revisit analysis for retail Wi-Fi: The same person is counted as a new device every time they connect, inflating the numbers. This method is no longer reliable.
• MAC filtering whitelists on routers and apartment-wide internet: The device is denied access because its actual MAC doesn't match the registered one. You must guide users to turn off the "Private Wi-Fi Address" (iOS) or "Use randomized MAC" (Android) setting for that specific network.
• Static IP assignments via DHCP based on MAC address: The reservation becomes meaningless as the address changes.

Web Servers Cannot See a Visitor's MAC Address

In practice, developers are often asked to "collect visitor MAC addresses to identify their devices." This is impossible. MAC addresses are only meaningful on the same link (i.e., within the same switch or Wi-Fi network). The moment a packet crosses a router, the MAC address is replaced with that of the next hop. A server only ever sees the MAC address of the router directly in front of it.

In other words, a user's MAC address fundamentally cannot travel across the internet. Browsers do not have an API to access it. If you need to identify a device, the correct solutions are cookies, device tokens, or user authentication. When this request comes up, you should explain that it is technically impossible.

Usage in VMs and Containers

This is one of the most common use cases for this tool. When you clone a VM image, the MAC address is cloned along with it. If you bring both online on the same network, DHCP might assign them the same IP, or their communications will get tangled. After cloning, you must generate and assign a new MAC address.

Hypervisors use their own OUIs. VMware assigns addresses starting with 00:50:56, and VirtualBox uses 08:00:27. If you need to maintain that format, you can enter the value in the "Fix OUI prefix" field. This will fix the first 3 bytes and randomize only the last 3 bytes.

Why Are EUI-64 and IPv6 Link-Local Addresses Shown?

At the bottom of the "Analyze MAC" tab, you'll find the EUI-64 and IPv6 Link-Local addresses. In the early days of IPv6, a common way to create an interface ID was to derive it from the MAC address — by inserting `FFFE` into the middle of the MAC to expand it to 64 bits and then inverting the U/L bit. The result is a link-local address that starts with `fe80::`.

The rule for inverting the bit is notoriously confusing, and manual calculations are often wrong. Use this feature when debugging IPv6 to confirm if "this link-local address" corresponds to "that device."

However, this method had a privacy problem: it left a hardware fingerprint in the IPv6 address, revealing that it was the same device connecting from anywhere. Because of this, modern operating systems now default to using temporary, randomly generated addresses. EUI-64 derived addresses are still seen on servers and network equipment but have become less common on user devices.