GUID / UUID v1 is a time + node based identifier that combines a high-resolution timestamp with additional bits (a clock sequence and a node identifier) so that systems can generate IDs without a central database while keeping collisions extremely unlikely.
GUID / UUID v1 is a time-based identifier that first appeared in 1997 as part of the original UUID specifications. It was later standardized in RFC 4122 in 2005.
V1 is not formally deprecated by any RFC and remains valid and supported by most GUID / UUID libraries. However, it is widely considered discouraged for new designs because it embeds creation time and historically included a device MAC address in the node field.
Modern implementations often randomize the node identifier to reduce privacy leakage, but this behavior is implementation-dependent and should not be assumed. For this reason, v1 is generally treated as a legacy or compatibility-focused format rather than a recommended default.
In practice, v1 GUIDs / UUIDs often look “sortable-ish” because the timestamp is embedded, but sorting behavior can depend on how GUID / UUID bytes are stored and compared. If you want time ordering with fewer privacy concerns, v7 is often preferred. If you want minimal embedded metadata and full randomness, v4 remains a common default.
1 and standard variant bits).Bit layout (practical view): GUIDs / UUIDs are 128-bit values shown as 32 hex digits with hyphens: 8-4-4-4-12. V1 uses these main regions: a timestamp, a clock sequence and a node identifier.
Fields (what exists): the timestamp is a 60-bit count of 100-nanosecond intervals since 1582-10-15 (Gregorian epoch), stored across the first three groups (with the version bits mixed in). The clock sequence is 14 bits used to help avoid duplicates when time is not strictly increasing. The node is 48 bits, historically derived from a MAC address but often randomized today (varies by implementation).
Field Bits Hex Digits Description
─────────────────────────────────────────────────────────────────────────
time_low 32 8 Low 32 bits of timestamp
time_mid 16 4 Middle 16 bits of timestamp
time_hi_and_version 16 4 High 12 bits of timestamp + 4-bit version (0001)
clock_seq_hi_and_reserved 8 2 2-bit variant (10) + 6 high bits of clock sequence
clock_seq_low 8 2 Low 8 bits of clock sequence
node 48 12 Node identifier (MAC address or random)
Timestamp reconstruction: the full 60-bit timestamp is reconstructed by combining: time_hi_and_version[11:0] (high 12 bits) + time_mid[15:0] (middle 16 bits) + time_low[31:0] (low 32 bits). The 4 high bits of time_hi_and_version contain the version number (0001 for v1).
Clock sequence: the full 14-bit clock sequence is formed from clock_seq_hi_and_reserved[5:0] (6 bits) + clock_seq_low[7:0] (8 bits). The 2 high bits of clock_seq_hi_and_reserved are the variant bits (10 for RFC 4122).
Ordering behavior: v1 contains time information, but it is not a simple "timestamp prefix" in the string. Depending on storage/byte order, v1 may not sort exactly by creation time in your database or programming platform. Treat v1 as time-correlated, not guaranteed perfectly sortable.
Try our GUID / UUID Inspector and see for yourself what fields are available.
Canonical format: 8-4-4-4-12
Example (v1): 6f9619ff-8b86-11d0-b42d-00c04fc964ff
Layout: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
^ ^
| └─ N = Variant: is typically 8, 9, a or b (RFC variant)
└────── M = Version: first hex digit of the 3rd group is "1" for v1
Practical rule: in the canonical string, the version is the first hex digit of the third group. For v1 it is 1. The variant is indicated by the high bits of the fourth group (often rendered as 8-b in hex for the common standard variant).
GUID / UUID v1 is usually a poor choice because it can leak creation time and possibly node-related metadata (MAC address). If you want time ordering with fewer privacy surprises, v7 is often preferred. If you want minimal embedded metadata, v4 remains a common default.
These articles expand on related concepts, formats and practical considerations.