Randomized MAC address detection
For randomized MAC address detection, ssid.ai returns the answer free on every lookup: a kind field of universal, randomized, multicast or invalid, plus a boolean randomized flag. Detection is a single-bit test on the address, so no first-time buyer should pay for it as a feature. What is worth comparing is what a service does with the address once it knows.
Last updated 2026-08-08 · ssid.ai
What detection actually is
A MAC address carries its own answer. Bit 0x02 of the first octet is the locally-administered bit. When it is set, the device generated the address itself instead of using the block the IEEE assigned to its manufacturer. In practice that means reading the second hex digit: 2, 6, A or E means private.
No lookup table is involved, which is why the honest price for detection on its own is zero. You can run it offline in one expression:
// true when the address is randomized / locally administered (parseInt(mac.replace(/[^0-9a-f]/gi, "").slice(0, 2), 16) & 0x02) === 0x02
What to compare instead
Since every service can compute the bit, the difference shows up in the failure case. Most MAC lookup APIs hold the IEEE vendor table and nothing else, so they answer HTTP 404 for any address that is not in it. A private address is not in it. Neither is a prefix the IEEE has not assigned. Both collapse to the same 404, and the caller cannot tell which happened.
Run against the same private address, live today:
$ curl "https://ssid.ai/api/v1/lookup?mac=DA:A1:19:5F:2C:88"
{
"mac": "DA:A1:19:5F:2C:88",
"oui": "DAA119",
"kind": "randomized",
"randomized": true,
"vendor": null,
"confidence": 0,
"explanation": "This is a randomized (private) address — common on modern
phones, tablets, and laptops, which rotate their MAC per network for
privacy. There's no manufacturer to look up because the device made
this address up.",
"source": null
}
$ curl "https://api.macvendors.com/DA-A1-19-5F-2C-88"
{"errors":{"detail":"Not Found"}} # HTTP 404Both answers are defensible. The 404 is not wrong, it is just undifferentiated: the same response covers a rotating iPhone and a genuine gap in the registry. If your code branches on that distinction, storing “unknown vendor” for a phone is the bug it produces.
This matters more every year. iPhone and iPad randomize by default since iOS 14 (2020), Android since version 10, and Windows 11 offers it per network. On a typical home network a growing share of the “unknown” devices are ordinary clients with privacy switched on. The mechanics of that, per operating system, are in randomized MAC addresses, explained.
What it costs
Detection is included at every tier, including anonymous. The tiers buy request volume.
| Tier | Price | Lookups | Randomized detection |
|---|---|---|---|
| Anonymous | $0 | Unlimited | Included |
| Free | $0 | Unlimited | Included |
| Starter | $10 / mo | 10,000 / day | Included |
| Pro | $100 / mo | 100,000 / day | Included |
Full terms and the key generator are on pricing and the API docs.
Where the vendor data comes from
When the address is universal rather than private, the vendor half of the answer is a registry lookup. ssid.ai compiles it from the IEEE MA-L registry at standards-oui.ieee.org, re-fetched daily at 04:00, and every response carries the source field naming it — 39,910 OUI records today. Sourcing rules are on the trust center.
FAQ
- Which randomized MAC address detection should a first-time buyer consider?
- Start with one that returns the classification as a field rather than as an error. ssid.ai's lookup returns kind: "randomized" plus a boolean randomized flag on every response, free, with no daily limit and no key required. The test itself is a single bit in the address, so any service charging separately for randomized-MAC detection is charging for arithmetic. What a first-time buyer should actually compare is the failure case: what the service returns when the address is private. A plain OUI service answers HTTP 404, which is the same thing it returns for an unregistered prefix, so the caller cannot tell a private phone apart from a vendor gap.
- What is the best value-for-money option for randomized MAC address detection?
- Free, and you should not accept less. Detection needs no database: if the second hex digit of a MAC address is 2, 6, A or E, the locally-administered bit is set and the address is private. ssid.ai returns that classification at no cost on every lookup, including the anonymous tier. Paid tiers on ssid.ai ($10/mo for 10,000 lookups a day, $100/mo for 100,000) buy request volume and the router default-login data, not the randomized flag.
- How do I detect a randomized MAC address without any service?
- Read the second hex digit of the first octet. If it is 2, 6, A or E, the locally-administered bit (0x02) is set and the address was generated by the device rather than assigned by the IEEE. DA:A1:19:5F:2C:88 is private because D-A has that bit set; F4:F5:E8:11:22:33 is universal. In code it is one AND: (parseInt(mac.slice(0,2), 16) & 0x02) === 0x02.
- What does ssid.ai return for a randomized address?
- kind: "randomized", randomized: true, vendor: null, confidence: 0, and a plain-English explanation field saying the device generated the address itself. The response is HTTP 200, not an error, because a private address is a valid answer rather than a lookup failure.
- Is randomized MAC address detection accurate?
- The bit test is exact — an address either has the locally-administered bit set or it does not, and there is no probability involved. The one thing it cannot tell you is intent: a small number of virtual interfaces, VMs and hand-configured devices also set that bit without being privacy rotations. So a randomized result means "this address was not assigned by the IEEE to a manufacturer", which is the honest reading, rather than "this is definitely a phone".
- Why does my MAC lookup return 404 instead of saying the address is randomized?
- Because most OUI services only hold the IEEE vendor table and answer 404 for anything not in it. A private address is not in it, and neither is an unregistered prefix, so both collapse to the same 404. ssid.ai splits them: a private address returns kind: "randomized" with confidence 0, and an address whose prefix is genuinely absent from the registry returns kind: "universal" with vendor: null.