uuid.lolUUID v1
Generate one- Version
- 1 (Time and MAC based)
- Variant
- RFC 9562
- Timestamp
- 2023-12-31T23:59:50.000Z
- Clock sequence
- 2603
- Node
- 03:1A:2B:3C:4D:5ELeaked
- Bytes
- AE D6 9F 00 A8 38 11 EE 8A 2B 03 1A 2B 3C 4D 5E
What a MAC Address Is, and Which IDs Actually Contain One
UUID v1 and v6 are the only formats here that can contain a MAC address. Both carry a 48-bit node field, and RFC 9562 §5.1 lets that field hold the machine's real IEEE 802 address.
Most modern libraries fill it with random bits instead, so a v1 or v6 UUID doesn't necessarily leak hardware. ULID, KSUID, Nano ID, and Cuid2 have no node field at all.
Which ID formats contain a MAC address?
Two, and only sometimes.
| Format | Contains a MAC address | Why |
|---|---|---|
| UUID v1 | Possibly | 48-bit node field: real MAC, or random with the multicast bit set |
| UUID v6 | Possibly | Same node field as v1, timestamp reordered to sort |
| UUID v3, v5 | No | Hash of a namespace and a name |
| UUID v4 | No | 122 random bits, no node field |
| UUID v7, v8 | No | Timestamp plus random bits, or application-defined bits |
| ULID | No | Timestamp plus 80 random bits, no node field |
| KSUID | No | Timestamp plus 128 random bits |
| Nano ID | No | Random end to end |
| Cuid, Cuid2 | No | A counter and hash, not hardware |
| TypeID | No | A UUID v7 re-encoded, so it inherits v7's fields |
| ObjectId | No | Old drivers hashed the hostname; current drivers use a per-process random value |
| Snowflake | No | Worker ID is assigned by the operator, not read from a NIC |
Paste your own ID into the decoder to see exactly which fields it carries.
Where is the node field in a UUID?
The node field is the last 48 bits of a v1 or v6 UUID, bits 80 through 127, the final six bytes. Both versions put it in the same place; only the timestamp fields before it are reordered.
| UUID version | Node field offset | Width | Byte range |
|---|---|---|---|
| v1 | bit 80 | 48 bits | bytes 10–15 |
| v6 | bit 80 | 48 bits | bytes 10–15 |
Pick a format below to see the node field against the rest of the 128 bits, or jump straight to a generator: UUID v1 or UUID v6.
| Field | Bit offset | Width (bits) | What it holds |
|---|---|---|---|
| time_low | 0 | 32 | Low 32 bits of the 60-bit timestamp, in 100-nanosecond intervals since 1582-10-15. |
| time_mid | 32 | 16 | Middle 16 bits of the timestamp. |
| version | 48 | 4 | Fixed to 0001, marking this a version 1 UUID. |
| time_high | 52 | 12 | High 12 bits of the timestamp. |
| variant | 64 | 2 | Fixed to 10, the RFC 9562 variant. |
| clock_seq | 66 | 14 | Randomized or incrementing, so the clock moving backwards never repeats an ID. |
| node | 80 | 48 | The generating node's IEEE 802 MAC address, or a random value with its multicast bit set. |
How do I tell if a node field is a real MAC address?
Check whether the least significant bit of the node field's first byte is set. RFC 9562 §6.10 requires implementations that generate a random node to set that bit to 1, because it's the unicast/multicast bit, and a real, burned-in IEEE 802 address never has it set.
A node field with an odd first byte is random. One with an even first byte might be a genuine MAC address, read from the machine that minted the UUID.
The example below decodes to node 03:1A:2B:3C:4D:5E. Its first byte, 03,
is odd in binary (00000011), so the multicast bit is set: this is a
randomized node, not a real network card address.
You can run the same check yourself:
function nodeIsRandomized(uuid) {
const node = uuid.split("-")[4]; // last group, the 48-bit node field
const firstByte = parseInt(node.slice(0, 2), 16);
return (firstByte & 1) === 1; // multicast bit, per RFC 9562 §6.10
}
nodeIsRandomized("aed69f00-a838-11ee-8a2b-031a2b3c4d5e"); // true
What is a MAC address?
A MAC address is 48 bits, written as six hex pairs. The first 24 bits are an
Organizationally Unique Identifier the IEEE assigns to a manufacturer,
so 00:0A:95 tells you the vendor before you've seen the rest of the
address.
The last 24 bits are chosen by that manufacturer, usually sequentially off a production line, so they are not random and not secret. Anyone who can read a device's network settings can read its MAC address.
Why did UUID stop putting a real MAC address in new IDs?
A MAC address is stable. It doesn't change on reboot, doesn't rotate, and doesn't depend on which network the machine joins. That stability is exactly what makes a v1 UUID with a real node field a durable hardware fingerprint: every ID that machine ever mints carries the same 48 bits, so any two IDs sharing a node field came from the same physical NIC.
That is a cost, not a feature. In 1999, Microsoft Office embedded a GUID (a UUID v1) in every document, with the node field derived from the author's Ethernet adapter, and The Register reported at the time that the same identifier turned up in a user's online registration data, tying documents to machines. Weeks later, investigators traced the Melissa email virus back to its author by matching that same embedded identifier across documents, according to the account in Wikipedia's history of the case.
RFC 9562 formalized the fix in §6.10: generate 48 random bits and set the multicast bit, so the field still looks like a node field without identifying any specific hardware. UUID v7 goes further and drops the node field entirely.
Common questions
Does UUID v4 contain a MAC address?
No. Version 4 is 122 bits from a CSPRNG with no structure beyond the version and variant nibbles, so there's no field a MAC address could occupy. Generate a UUID v4 and every character below the version marker is random.
Does UUID v7 contain a MAC address?
No. v7 replaced the node field with a 48-bit Unix millisecond timestamp and filled the rest with random bits. Nothing in a v7 UUID reads from a NIC.
Do Nano ID or Cuid2 leak the machine that generated them?
No. Neither has a hardware field. A Nano ID is random from end to end, and Cuid2 is a hash with no documented machine or hostname component.
Does MongoDB's ObjectId contain a MAC address?
No, and it never did. Older MongoDB drivers derived part of the value from a hash of the machine's hostname, not its MAC address. Current drivers use a single 5-byte value chosen randomly once per process.
If my database is full of old v1 UUIDs, are they leaking MAC addresses right now?
Only if whatever generated them read a real MAC address rather than randomizing the node field. Decode a few of them and check the node field's first byte: odd means random, even means it's worth treating as identifying, and worth migrating new rows away from.