What the validator actually checks
A valid hardware address is exactly 12 hexadecimal digits arranged as six bytes. The validator accepts the separators people actually use in the wild: colons (00:1A:2B:3C:4D:5E), hyphens (00-1A-2B-3C-4D-5E), Cisco dotted pairs (001a.2b3c.4d5e) and no separator at all (001A2B3C4D5E). It then normalises the result to uppercase colon form so that values copied out of a spreadsheet, a switch config and a vendor datasheet can be compared side by side.
The common failure modes are a wrong digit count, a non-hex character such as G or Z, a separator in the wrong place, or two different separators in one string. Each of those breaks a downstream parser, and a broken line in a DHCP reservation file or a switch port description is far more expensive to trace than the two seconds it takes to check the value first.
Reading the two flag bits
The first octet decides what kind of address you are holding. Flip it into binary: the rightmost bit is the individual/group flag, and when it is 1 the address is a multicast group, not a device. The bit immediately to its left is the universal/local flag, and when it is 1 the address was assigned locally, which is what virtual machines, container bridges and privacy features use. 02:00:5E:10:00:01 is a classic locally administered address because 02 in binary is 0000 0010.
Two of the 48 bits are flags, which leaves 46 bits of identity. Those split into the 24-bit OUI at the front and the vendor-assigned device portion at the back; because the flags sit inside the OUI, a manufacturer really controls only 22 of its 24 bits. The validator can confirm shape and flag bits, but it cannot tell you which company owns a prefix without querying the IEEE registry, and it cannot know whether a well-formed universal address was ever actually manufactured.
A batch from three sources
Take a batch pasted from three sources. 00:1a:2b:3c:4d:5e passes and comes back as 00:1A:2B:3C:4D:5E with the local bit clear, so it claims a vendor block. 001a.2b3c.4d5e passes as Cisco notation and normalises to the same value. 00:1A:2B:3C:4D fails on digit count with only ten digits. 00:1A:2B:3C:4D:5G fails on the character G. 00:1A-2B:3C:4D:5E fails because it mixes two separators. Five lines, two usable values, and the three failures would each have produced a bad config line.
Two syntactically valid strings deserve a second look. FF:FF:FF:FF:FF:FF is the broadcast address and is never a device, and 00:00:00:00:00:00 is the all-zero address that some drivers report when the hardware has not been initialised. Both pass a hex check but should be rejected by whatever validation rule sits above it, such as a uniqueness constraint or a check that the value is not all ones.
Where format validation pays for itself
Asset inventories and CSV imports are the usual battleground: a thousand rows from three field engineers, half of them written with hyphens and half with colons, and one row where a capital O was typed instead of a zero. Normalising first means your comparison and de-duplication logic can work on a single canonical form. The same applies to DHCP reservation lists, Wi-Fi access control lists and monitoring inventories keyed by hardware address.
Generate test values with the MAC address generator, then run them through here before pasting them into a configuration. If you are dealing with raw packet payloads rather than addresses, text to hex converter handles the byte-level view, and IP lookup covers the address that actually crosses a router.