How to Validate MAC Addresses in a Pasted List Before You Trust It

A MAC address looks simple until you have three hundred of them pasted out of a switch dump, a spreadsheet, and two support tickets. Some are upper case, some lower, a few are missing a byte, and one of them has a typo where someone wrote a G instead of a 6. Load that list straight into an allowlist or a network access control rule and the bad rows fail silently at the worst possible moment.

The MAC Address List Validator checks each row one at a time, marks every entry pass or fail, and prints the reason next to the failures so you know exactly what to fix. Everything runs in your browser tab. Nothing about how it decides "valid" is a mystery, so this post walks through the rule it applies and shows it on a real list.

What a valid MAC address actually is

A MAC address is 48 bits. Written out, that is 12 hexadecimal digits, where each hex digit covers 4 bits and only the characters 0–9 and A–F (case-insensitive) are legal. The 12 digits are grouped into six byte pairs, and the pairs are joined by a separator so the address is readable.

That definition gives you a hard test you can apply without thinking about hardware at all:

A string with 10 hex digits is not 48 bits. It is short by a full byte and gets flagged.
A string containing a non-hex character — G, Z, a stray space, a quote — cannot be a hex address and gets flagged.
A string with the wrong number of groups, like five pairs instead of six, is flagged because it is not 48 bits laid out correctly.

So 00:1A:2B:3C:4D looks like a MAC at a glance, but it only has five groups. It is missing a byte, and the validator catches it.

The exact notations this tool accepts

This is the part worth pinning down, because "MAC address" is written several ways in the wild and not all of them pass here. The validator accepts a row as valid only when it matches six two-digit hex byte pairs separated by a colon or a hyphen. Concretely:

Colon notation: 00:1A:2B:3C:4D:5E — valid.
Hyphen notation: 00-1A-2B-3C-4D-5E — valid.
Case does not matter: aa:bb:cc:dd:ee:ff and AA:BB:CC:DD:EE:FF both pass.

What it does not accept as valid:

Cisco dotted-quad notation — 001A.2B3C.4D5E (three groups of four hex digits separated by dots). Cisco gear prints addresses this way, but this validator's rule only recognizes the colon and hyphen forms, so a dotted-quad row is flagged. If your inventory comes off Cisco hardware, convert those rows to colon or hyphen pairs first.
No separators at all — a bare 001A2B3C4D5E is flagged, because the rule expects the six-group, separated layout.
Mixed or stray separators — a string where the grouping is broken is flagged.

Knowing this up front saves confusion: a flagged row is not always "garbage," it might just be a notation the validator does not count as canonical. Either way, it lands in the fail list with its reason so you can decide.

A worked example

Here is a small list with the kind of mix you actually get. Paste it in and the tool checks each line:

00:1A:2B:3C:4D:5E
AA-BB-CC-DD-EE-FF
00:1A:2B:3C:4D
00:1G:2B:3C:4D:5E
001A.2B3C.4D5E
aa:bb:cc:dd:ee:ff

The pass/fail report comes back like this:

| Row | Address | Result | Reason | |-----|---------|--------|--------| | 1 | 00:1A:2B:3C:4D:5E | valid | OK | | 2 | AA-BB-CC-DD-EE-FF | valid | OK | | 3 | 00:1A:2B:3C:4D | invalid | MAC address must contain six hex byte pairs separated by : or -. | | 4 | 00:1G:2B:3C:4D:5E | invalid | MAC address must contain six hex byte pairs separated by : or -. | | 5 | 001A.2B3C.4D5E | invalid | MAC address must contain six hex byte pairs separated by : or -. | | 6 | aa:bb:cc:dd:ee:ff | valid | OK |

Row 3 has only five groups, so it is missing a byte. Row 4 has the right shape but a G where a hex digit must be. Row 5 is the Cisco dotted-quad form, which the rule does not recognize. The three valid rows pass cleanly, including the lower-case one, because case is ignored. The report keeps the bad rows on purpose — the failures are the whole point of validating, since those are the entries you hand back for repair.

Cleaning a real device inventory

When I clean up a device inventory, I never trust the source format. The list usually arrives as a CSV export glued together with a couple of pasted ticket replies, and the formatting is inconsistent the moment more than one person touched it. My routine is short: paste the whole thing, read the fail rows first, and fix or drop them before anything else. The reason column tells me whether a row is genuinely broken (a missing byte, a typo) or just written in a notation I need to convert. Once the fail list is empty, I keep unique rows only so duplicates from the merge don't sneak through, sort the output, and download a CSV with line numbers as the audit trail. That artifact is what goes into the allowlist — not the raw paste.

One caution worth repeating: a valid format is not proof the device exists. The validator confirms a string is a well-formed 48-bit address; it says nothing about whether that hardware is real or reachable. Treat the pass list as "safe to load," not "verified."

Where this fits with the rest of the workflow

Validation is one step. If your list needs more than a pass/fail check, the sibling tools handle the adjacent jobs. Use the MAC Address Normalizer to rewrite every valid row into one consistent separator and case before import. Use the MAC Address Deduplicator to collapse repeats from a merged export. If your source text is a log or a copied web page rather than a clean list, the MAC Address Extractor pulls the addresses out first, and the MAC Address List Converter turns a clean list into JSON, a SQL IN clause, or a TypeScript union when you need it in code.

The common thread is that you do the messy checking once, in the browser, and hand off an artifact you can defend. Start with validation so you know what you are working with, then normalize, dedupe, and convert from a list you already trust.

Made by Toolora · Updated 2026-06-13