A switch logs a MAC in Cisco dotted-triplet form (aabb.ccdd.eeff). The vendor of a wireless access point logs it in hyphen form (AA-BB-CC-DD-EE-FF). The DHCP server logs it in colon form (aa:bb:cc:dd:ee:ff). The ticket the user pasted has it as one twelve-character blob, lowercase, no separators. All four are the same address, and any one of them needs to go into a portal that only accepts one of the other three formats. PortJar’s MAC Address Formatter is for the moment you stop typing colons by hand and want a clean, normalized answer back.
What the tool does
MAC Address Formatter accepts any common MAC notation — aa:bb:cc:dd:ee:ff, AA-BB-CC-DD-EE-FF, aabb.ccdd.eeff, or twelve hex characters with no separator at all — and returns the address in every format at once. It also reads the two structural bits of the first octet: the Universal/Local bit (bit 1, which marks whether the address came from a vendor OUI block or was locally assigned) and the Individual/Group bit (bit 0, which marks unicast vs multicast / broadcast).
It runs entirely client-side, so a MAC pasted in never leaves the browser tab. That matters less than it does for secrets, but MAC addresses still count as device identifiers and you may not want them in a third-party log.
How to use it
Open portjar.com/tools/mac-formatter, paste the MAC in whatever form you have it, hit Run, and all formats appear together. The example chips load aa:bb:cc:dd:ee:ff and 00-1A-2B-3C-4D-5E if you want a clean round-trip to confirm the tool agrees with you on case and separators. Output includes a flag if the address is locally administered (often a clue you are looking at a VM, container, or hypervisor-assigned NIC rather than physical hardware) or if it is multicast (anything other than a normal unicast destination should make you stop and check).
When you’d reach for it
- Onboarding a device into a portal that only accepts one specific format. The captive portal wants colons; your switch logs use Cisco triplets; the work order arrived as twelve unbroken hex characters. One paste, three correct outputs, zero typos.
- Diagnosing a “MAC address not recognized” error in a 802.1X / RADIUS deployment. Case and separator are usually irrelevant in the RADIUS exchange itself, but the database the policy server reads from may be strict. Normalize first, then look at the rule.
- Spotting that a NIC is a virtualized or hypervisor-assigned MAC rather than a physical adapter. The Universal/Local flag tells you immediately. A locally-administered MAC on something the operator believes is bare metal is a finding worth pursuing — usually a forgotten bridge, a hot-add NIC, or a VM that was never tagged correctly.
- Catching a multicast address pasted where a unicast one was expected. The tool flags it; without that flag, the same address would silently fail or behave unpredictably anywhere it was used as a destination.
- Reading an OUI vendor prefix at a glance. The first three octets identify the manufacturer registered with the IEEE; once you have the address in a clean format you can paste those six characters into any OUI lookup to confirm the vendor matches what the ticket claims.
What to make of the output
If all three formats look right and the bit flags are clean (universal, individual), you have a normal vendor-assigned unicast MAC — paste whichever format the destination system wants and move on.
If the locally-administered flag is set, the address was not pulled from a vendor’s IEEE-registered OUI block. The most common sources: a hypervisor (VMware, Hyper-V, KVM, and Xen all use predictable locally-administered ranges); container networking (Docker, containerd, podman assign locally-administered MACs to virtual interfaces); a NIC team or bridge that derived a synthetic MAC from its members; or a device whose firmware lets you override the MAC. None of these are wrong on their own, but if the operator believes they are looking at physical hardware, this flag tells you they probably are not.
If the multicast flag is set, the address is not a valid destination for unicast traffic — it is a group address, a broadcast, or in the case of 01:00:5e:... an IPv4 multicast translation, or 33:33:... an IPv6 multicast translation. A multicast MAC in a place that wanted a unicast MAC is almost always the result of someone copying the wrong row from a table.
If the input rejects as invalid, you either have fewer than twelve hex characters (one character was lost in copy-paste), or non-hex characters slipped in (most commonly an O for a 0, a l for a 1, or a smart quote that came from a word processor). Re-paste from a monospace context and try again.
Stack Harbor uses MAC formatting as part of routine network-onboarding and asset-reconciliation work we run inside environment management as a service.