| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} | |
| No details. | ||
| Provider | Transport | Status | HTTP | Latency | Message | Copy |
|---|---|---|---|---|---|---|
| {{ row.provider }} | {{ row.transport }} | {{ row.status }} | {{ row.httpStatus }} | {{ row.latency }} | {{ row.message }} | |
| No provider evidence. | ||||||
| Priority | Action | Why now | Next check | Cadence | Copy |
|---|---|---|---|---|---|
| {{ row.priority }} | {{ row.action }} | {{ row.reason }} | {{ row.next_check }} | {{ row.cadence }} | |
| No identity actions available. | |||||
A MAC address is the link-layer identifier a network interface uses on the local segment. It matters in ordinary administration because Wi-Fi allowlists, DHCP reservations, switch logs, inventory exports, and privacy features often all refer to the same address in slightly different forms. This page turns that low-level identifier into a readable profile so you can see what the bits, prefixes, and lookup responses are actually telling you.
The package starts by normalizing one pasted address into several common representations, then it derives the first-octet flags, address class, OUI prefix, special-use hints, and IPv6-related conversions that can be built from the supplied value alone. If remote provider lookup is enabled, it also asks the selected vendor sources for organization and assignment-block details and records how each route responded.
That mix is useful when a wireless client looks private instead of vendor-stable, when a hypervisor prefix needs to be separated from a physical device clue, when an IPv6 interface identifier needs to be traced back to a hardware-style address, or when a pasted ticket contains a noisy string and you want the first valid MAC token pulled out cleanly.
The main caution is that structure is not identity. A globally administered unicast prefix can still be spoofed, a locally administered address can be manually assigned instead of randomized, and a vendor name only tells you who owns an assignment block, not which exact product is on the wire. The page is strongest as a parsing and troubleshooting aid, not as proof of device authenticity.
Privacy deserves the same restraint. The address field is synchronized through the page URL once you use the tool, and remote vendor lookups disclose the queried address to the selected lookup path. That is often acceptable in a lab or support workflow, but it is still worth treating MAC data as sensitive operational context rather than harmless clipboard text.
Start with the address itself and leave the provider mode on Auto unless you already know why you want a narrower path. The package extracts the first MAC-like token from the first non-empty line, so it works well with copied logs, chat messages, or switch output that contains extra text around the value. If several lines are pasted, only the first line is processed and the rest are reported as ignored.
The next decision is whether you want local structure only or outside vendor corroboration. None keeps the run entirely on locally derived fields such as OUI, I/G Bit, U/L Bit, Modified EUI-64, and Link-local Candidate. That is the better choice when you only need format and flag analysis or when the address should not be sent to outside lookup services.
Provider-backed mode matters when vendor context changes the decision. maclookup.app can return richer assignment metadata such as country, block range, and organization strings. macvendors.com is lighter and often useful as a secondary check when you only need a vendor label. Auto tries both in order and keeps the first successful match, while the Evidence view shows whether a provider passed, warned, or failed on each transport route.
The Safety sensitivity setting does not change the parsed bits of the address. It changes how aggressively the Identity Actions tab recommends follow-up. In balanced mode the page gives practical next steps. In strict mode it leans harder toward short review cadences and reduced trust when the address looks private, randomized, unresolved, or proxy-mediated.
| Situation | Best place to look first | Why it helps |
|---|---|---|
| Need to confirm the address format and flags | Details | Shows canonical formatting, OUI, I/G and U/L bits, address class, and local derivations in one table. |
| Need to know whether vendor evidence is trustworthy | Evidence | Shows provider, transport path, HTTP outcome, latency, and whether a match was actually found. |
| Need a short operational recommendation | Identity Actions | Turns the parsed flags and lookup conditions into concrete follow-up actions and review cadence. |
| Need to export the full normalized record | JSON | Keeps all derived fields, provider details, and lookup notes together for handoff or archiving. |
The parser accepts common EUI-48 and EUI-64 notations, including colon-delimited, hyphen-delimited, dotted, and compact hexadecimal forms. It strips wrappers and separators, requires either 12 or 16 hexadecimal digits, and then rebuilds the address into canonical colon form, dashed form, dotted form, byte count, and a compact uppercase hex string. If the pasted line contains surrounding text, the first MAC-like token is extracted and preserved as the normalized input value.
The first octet drives most of the low-level interpretation. The least significant bit is treated as the I/G bit, which separates individual from group addressing. The next bit is treated as the U/L bit, which separates universally administered from locally administered values. From that one octet the package labels the address as unicast, multicast, broadcast, or all-zero, and it assigns an administrative class of either universally administered or locally administered.
That distinction matters because vendor attribution and privacy interpretation diverge there. A universally administered unicast address is the case most likely to map back to an IEEE-assigned prefix. A locally administered unicast address often appears in virtualization, manually assigned ranges, and privacy-preserving Wi-Fi features. The package therefore marks locally administered unicast addresses as Likely randomized, while still leaving room for the operator to decide whether the address is actually ephemeral, manually set, or lab-assigned.
The page also derives several IPv6-related helper values. For a 48-bit MAC it flips the U/L bit, inserts FF:FE, and builds a Modified EUI-64 value, a compact interface identifier, and a fe80:: link-local candidate. For a 64-bit address it formats the interface identifier directly and, when the middle bytes are FF:FE, it reconstructs the corresponding 48-bit address candidate. These are deterministic conversions, not a live probe of the host's current IPv6 configuration.
| Field | What the package derives | What it does not prove |
|---|---|---|
| OUI | The first 24 bits of the address, shown in hex and colon form. | A confirmed device manufacturer for a private or spoofed address. |
| Prefix (36-bit) | A longer prefix slice that can help compare assignment ranges. | An official registry result by itself. |
| Randomization Likelihood | A package-level interpretation based on multicast, broadcast, all-zero, or locally administered state. | Proof that the address rotates automatically on the current network. |
| Modified EUI-64 and SLAAC IID | Deterministic IPv6-oriented conversions from the supplied bytes. | Evidence that the device is actually advertising or using that IPv6 address. |
| Special Use | Known patterns such as broadcast, IPv4 multicast mapping, IPv6 multicast mapping, bridge-control, VRRP, or HSRP ranges. | The complete role of the device or protocol on the network. |
Remote lookup is intentionally conservative in structure. The page builds a provider sequence from the chosen mode, then queries each provider through a same-origin proxy route first and, when proxy fallback is enabled, through an AllOrigins route second. Each request is wrapped in an abortable timeout clamped between 500 and 15000 milliseconds. A successful route can still produce a warning if the provider responds without a vendor match.
The Details and Evidence tables support CSV copy, CSV download, and DOCX export. Identity Actions has its own export path, and JSON can be copied or downloaded directly. The package does not use a tool-specific backend helper or browser storage API for state retention, but it does synchronize the active parameters through the shared query-parameter mixin, which means the address, provider choice, timeout, proxy-fallback setting, and sensitivity mode can all appear in the page URL after use.
The practical limit is that outside vendor sources are not authoritative for every address class. If the current value is private, randomized, recently reassigned, missing from the source dataset, or blocked by the transport path, the page will still give you a strong local structural read but a weak vendor conclusion. That is expected behavior, not necessarily a parsing failure.
The fastest interpretation usually starts with three fields together: Address Class, Admin Class, and Vendor. A universally administered unicast address with a returned vendor string is the cleanest case. A locally administered unicast address with no vendor match is the opposite. It often points to privacy mode, virtualization, manual addressing, or a block that the current sources do not expose clearly.
Randomization Likelihood should be read as a caution label, not a verdict about intent. The page is telling you that the bit pattern matches a class often used for private or session-scoped addresses. That can be the right explanation for a phone or laptop on Wi-Fi, but it can also describe a deliberate local policy choice in a lab, a hypervisor bridge, or a manually configured interface.
Vendor unresolved also needs context. It may mean the address is private, that the registry prefix is absent from the current provider, that the provider returned an error, or that only a proxy path succeeded and the response body was thin. That is why the Evidence tab matters. It separates "no vendor match came back" from "the lookup path itself failed."
| Outcome pattern | Likely meaning | Reasonable next step |
|---|---|---|
| Globally assigned unicast with vendor match | The address structure and provider record are aligned. | Use the result as a troubleshooting baseline, while remembering it is still not proof of physical device identity. |
| Locally administered unicast with no vendor match | Privacy mode, local assignment, or virtualization is more plausible than stable hardware attribution. | Treat the address as ephemeral or policy-scoped unless another asset source says otherwise. |
| Multicast or special-use prefix | The address identifies a group, protocol mapping, or virtual function rather than one ordinary endpoint. | Interpret it in protocol context before chasing vendor identity. |
| Provider warnings or proxy-only evidence | The parsing succeeded, but the vendor conclusion is less stable than usual. | Recheck later or compare with a trusted local inventory source. |
The IPv6 helper rows should be read just as carefully. A Link-local Candidate is an arithmetic derivation from the supplied bytes. It does not show that the interface has actually formed or advertised that address, and it does not tell you whether privacy extensions or stable-secret addressing have replaced EUI-derived behavior on the host.
A support ticket includes a laptop MAC that starts with a locally administered unicast pattern and returns no vendor. The page marks it as likely randomized, keeps the structural details visible, and recommends shorter review cadence instead of long-lived vendor attribution. That is often the correct operational posture for modern client Wi-Fi behavior.
An address resolves to a local OUI hint associated with a hypervisor family and also carries a vendor match through one provider route. The combination tells you the interface may belong to a virtual machine or bridge context, which is more useful for troubleshooting than assuming the vendor string alone identifies a physical laptop or server model.
An operator has only a hardware-style MAC from an inventory note and wants a quick EUI-derived link-local candidate for comparison with router output. The page builds the Modified EUI-64 and the candidate fe80:: form immediately, saving manual bit flipping while still making clear that the derived address is a candidate, not a live discovery result.
No. It identifies the assignment block owner returned by the lookup source. That is useful context, but it does not prove product model, hardware authenticity, or current ownership of the interface.
No. It means the address is locally administered unicast, which is common in privacy features but can also appear in manual lab assignments and virtualized environments.
The address may be private, missing from the provider dataset, too new for the current source, or the transport path may have returned a warning or failure. The Evidence tab shows which case is closer.
No. It is only the deterministic EUI-based candidate derived from the supplied bytes. Real hosts can use other interface-identifier schemes instead.
Yes for structure analysis. Choose None as the provider mode and the page will skip remote vendor lookup, leaving only the local parsing and derivation logic.
FF:FE when starting from a 48-bit MAC.