MAC Address Generator

What is a MAC address?

A MAC (Media Access Control) address is the hardware identifier burned into - or assigned to - a network interface such as a Wi-Fi radio, an Ethernet port, or a Bluetooth controller. It operates at Layer 2 of the OSI model, the data-link layer, where switches forward frames based on these addresses long before any IP routing happens. Every frame that crosses an Ethernet or Wi-Fi link carries a source MAC and a destination MAC so the receiving hardware knows whether the frame is meant for it.

The standard MAC address is a 48-bit value, formally called an EUI-48 (Extended Unique Identifier, 48 bits) by the IEEE. Forty-eight bits is six bytes, which is why a MAC address is almost always written as six pairs of hexadecimal digits, for example 00:1B:44:11:3A:B7. Each pair represents one byte (an "octet"), and each hex digit represents four bits (a "nibble"). A newer 64-bit form, the EUI-64, exists for some technologies, but the classic six-byte EUI-48 is what you see on virtually every laptop, phone, router, and server.

Because 48 bits gives roughly 281 trillion possible combinations, the address space is enormous - which is exactly what makes random generation practical. The odds of two independently generated random addresses colliding on the same local network segment are vanishingly small, so generated addresses are safe to use for labs, testing, and simulation.

How a MAC address is structured: OUI and device portion

A 48-bit MAC address is split into two halves of 24 bits each. The first three octets form the OUI - the Organizationally Unique Identifier - which the IEEE Registration Authority assigns to a manufacturer. The last three octets are the device portion (sometimes called the NIC-specific part or the extension identifier), which the manufacturer assigns to make every interface it ships unique.

So in 00:1B:44:11:3A:B7, the OUI is 00:1B:44 and the device portion is 11:3A:B7. If you look up that OUI in the IEEE registry, it maps back to whichever company registered it. This is exactly how a MAC Address Lookup identifies the vendor behind a device: it reads the first 24 bits and matches them against the registry. When you generate an address in vendor mode on this page, the tool keeps a real, registered OUI for your chosen manufacturer and only randomizes the trailing 24 device bits, so the result is genuinely attributable to that vendor.

The two flag bits that make an address valid

Not every random string of twelve hex digits is a sensible MAC address. Two bits inside the very first octet change the meaning of the whole address, and getting them right is the difference between a valid generated address and a malformed one. Both bits live in the least-significant end of the first byte.

The I/G bit (unicast vs multicast)

The least-significant bit of the first octet is the Individual/Group bit, usually called the I/G bit. When this bit is 0, the address is a unicast address that identifies a single interface - which is what a normal device address should be. When the bit is 1, the address is a multicast or group address, meant to be delivered to many interfaces at once (for example the IPv4 multicast range that begins 01:00:5E). A generator that is producing device addresses must therefore leave this bit cleared so the output is unicast.

The U/L bit (universal vs local)

The second-least-significant bit of the first octet is the Universal/Local bit, the U/L bit. When it is 0, the address is universally administered - meaning it was assigned by the manufacturer from its registered OUI and is intended to be globally unique. When the bit is 1, the address is locally administered: it was set by software or an administrator and is not tied to any vendor's OUI. This is the bit modern phones and laptops flip when they perform MAC randomization for Wi-Fi privacy.

The 2 / 6 / A / E rule

Here is a shortcut that lets you verify a locally-administered unicast address at a glance. To make an address unicast you clear the I/G bit (bit value 1), and to make it locally administered you set the U/L bit (bit value 2). The combination forces the low nibble of the first byte to a specific set of values. In practice this means the second hexadecimal digit of a valid locally-administered unicast MAC address is always 2, 6, A, or E. For example 02:..., x6:..., xA:..., or xE:.... If you generate a "random" MAC for a lab and its second hex digit is anything else, the I/G or U/L bit is wrong. This page's locally-administered mode always satisfies the rule, which is why you will see addresses like A2:1B:44:... or 3E:9F:... but never a locally-administered address ending its first byte in an odd value.

How this generator produces a valid address

The tool never ships a hardcoded list of "random" addresses - that would not be random at all. Instead it asks your browser for cryptographically secure random bytes through the standard crypto.getRandomValues() API, the same primitive used for secure tokens, and then shapes those bytes to be valid:

• Locally-administered mode: six random bytes are drawn, then the first byte is adjusted with (byte & 0xFE) | 0x02. The & 0xFE clears the I/G bit so the address is unicast, and the | 0x02 sets the U/L bit so it is locally administered. The other five bytes stay fully random. The result always passes the 2/6/A/E check above.
• Vendor-prefix mode: the three OUI bytes for the vendor you pick are kept exactly as the IEEE registered them - the flag bits are deliberately not touched, because a real vendor OUI is universally administered (U/L = 0). Only the last three device bytes are randomized. Flipping the U/L bit here would turn, say, an Apple prefix into something no longer attributable to Apple, so the tool leaves the vendor's octets untouched.

Because the two modes treat the first octet differently, they are mutually exclusive: an address is either a vendor-attributable universally-administered address or a randomized locally-administered one, never both.

Format conventions: colon, hyphen, dot, and case

The same 48 bits can be written several ways, and different ecosystems prefer different ones. This generator supports all of the common conventions so you can paste the output straight into whatever expects it:

• Colon-separated (00:1B:44:11:3A:B7): six groups of two hex digits separated by colons. This is the most common form on Linux, macOS, and in most documentation.
• Hyphen-separated (00-1B-44-11-3A-B7): six groups of two separated by hyphens. Windows tends to display addresses this way.
• Cisco dot notation (001b.4411.3ab7): three groups of four hex digits separated by dots. Cisco IOS and many enterprise switches use this triple-group form - note it is not a dot between every byte.
• No separator (001B44113AB7): twelve bare hex digits, handy for scripts, CSV files, and config formats that strip punctuation.

Hexadecimal is case-insensitive - 1B and 1b represent the same value - so the upper/lower toggle is purely cosmetic. Pick whichever your target system or style guide prefers; many command-line tools emit lowercase while a lot of printed documentation uses uppercase.

When would you generate a MAC address?

Generating a MAC address is an everyday task in several fields, and almost never means cloning a real device's address. Common, legitimate reasons include:

• Lab and test environments: when you need a batch of unique interface identifiers for switches, DHCP scopes, or network simulations, generated locally-administered addresses give you collision-free values that won't clash with shipping hardware.
• Virtual machines and containers: hypervisors such as VMware, Hyper-V, KVM, and VirtualBox assign MAC addresses to virtual NICs. When you clone a VM or build one from a template you often need a fresh, valid address so two guests don't end up sharing one. Generators (and the hypervisor's own assignment ranges) produce these.
• MAC randomization and privacy: modern phones and laptops rotate a locally-administered address per network so that public Wi-Fi access points can't track a device across locations by its hardware address. Understanding the locally-administered format helps when you are reasoning about why a device's address keeps changing.
• Network simulation and education: when teaching Layer 2 concepts, building packet-capture exercises, or testing parsers and firmware, you need plausible addresses that obey the I/G and U/L rules without pointing at a real person's equipment.
• Provisioning and automation: infrastructure-as-code pipelines sometimes pre-allocate MAC addresses for interfaces before the hardware exists, drawing from a locally-administered range to avoid registry collisions.

A note on ethics and legality: deliberately setting your interface to impersonate another real device's MAC address (MAC spoofing) to bypass access controls or filtering can violate acceptable-use policies or law depending on context. Generating fresh locally-administered addresses for your own labs, VMs, and testing is a normal, benign activity - that is the use case this tool is built for.

Best practices and common pitfalls

Generating a valid address is only half the job; using it well avoids subtle bugs that can take hours to track down on a real network. A few practices keep generated addresses trouble-free:

• Prefer locally-administered addresses for anything you assign yourself. The locally-administered range exists precisely so administrators and software can mint addresses without risking a collision with a manufacturer's globally-unique value. If you invent a universally-administered address by hand, you might accidentally duplicate a real shipping device's MAC, and two interfaces with the same address on one Layer 2 segment will cause frames to be misdirected and dropped.
• Keep each address unique within a broadcast domain. A switch builds its forwarding table by learning which port a source MAC arrives on. If the same MAC appears on two ports, the switch flaps the entry back and forth, and connectivity becomes intermittent. When generating a batch, treat the list as a set and discard any (extremely unlikely) duplicates before deploying.
• Do not flip the multicast bit on a device address. If the I/G bit is set, switches and NICs treat the frame as a group address. A "device" whose source address is multicast is malformed and many stacks will silently drop its traffic. The locally-administered mode here always clears that bit for you.
• Remember that randomization changes reachability assumptions. Some networks pin DHCP reservations, captive-portal sessions, or access-control lists to a MAC address. A device that rotates its address per connection will look like a brand-new client each time, which is the privacy goal but can break "remember me" behaviour on a corporate or campus network.
• Match the format to the consumer. Pasting a Cisco-dotted address into a tool that expects colon-separated octets, or vice versa, is a frequent source of "invalid MAC" errors. Use the separator selector to emit exactly the shape your target system parses.

Frequently asked questions about generating MAC addresses

Are the generated addresses really random?

Yes. Each address is built from bytes returned by your browser's crypto.getRandomValues(), a cryptographically secure pseudo-random number generator, not from a fixed table. In locally-administered mode only the first byte is adjusted (to clear the I/G bit and set the U/L bit); the remaining five bytes are untouched random values, giving roughly 2.8 x 10^14 possible addresses.

Will a generated address collide with a real device?

For locally-administered addresses, collisions with shipping hardware are not possible by design: manufacturers only ship universally-administered addresses (U/L bit = 0), and this tool's random mode always sets the U/L bit, placing every output in the separate locally-administered space. The chance of two independently generated locally-administered addresses matching each other is astronomically small for any practical batch size.

Can I assign a generated address to my own network card?

On most operating systems you can override an interface's MAC address (often called "MAC spoofing" or "MAC cloning"), and a locally-administered address is the correct choice for that. This is legitimate for privacy, testing, and lab work on equipment you control. Setting your address to copy another person's real device in order to defeat access controls is a different matter and may breach policy or law, so stick to fresh locally-administered values.

Why does the second hex digit look limited?

That is the 2/6/A/E rule in action. A locally-administered unicast address must have the I/G bit clear and the U/L bit set, which constrains the low nibble of the first byte to exactly those four values. Seeing 2, 6, A, or E there is a quick confirmation that the address is well-formed, not a limitation of the randomness.

What is the difference between this and the lookup tool?

This page creates new valid addresses; the lookup tool reads an existing address and tells you its vendor and bit flags. They are complementary: generate a vendor-mode address here, paste it into the lookup, and you will see the manufacturer resolved from the OUI you selected.

Try the companion lookup tool

Once you have generated an address - especially a vendor-prefixed one - you can verify it with our MAC Address Lookup. Paste a generated vendor-mode address and the lookup will resolve it back to the same manufacturer, confirming the OUI was preserved. Paste a locally-administered address and the lookup will correctly report it as locally administered with no vendor, which is exactly what the U/L bit signals. To go deeper on the underlying concepts, read our guide on what a MAC address is.