GUID Version 1-8 - The Complete Comparison
Comprehensive comparison of all GUID versions (v1-v8). Understand the differences, use cases, security implications and performance characteristics of each version to choose the right one for your project.
GUID V1 - Time + Node Based Identifier
GUID 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.
Privacy warning: GUID / UUID v1 can leak creation time and historically could reveal the device MAC address through the node field. Modern implementations often randomize the node field, but this should not be assumed.
Version status and history
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 July 2005 and later updated in RFC 9562 in May 2024.
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.
Advantages of GUID / UUID v1
- Predictable structure: easy to validate (version nibble
1and standard variant bits). - Time-correlated: contains timestamp information which can be useful for debugging and tracking creation order.
- Wide support: v1 has been around since the original RFC 4122 and is supported by most GUID / UUID libraries.
Warnings for GUID / UUID v1
- Severe privacy leakage: encodes creation time and historically the node field could reveal a device MAC address. Many implementations randomize the node, but you should not assume that.
- Not ideal for public IDs: timestamps can make IDs more guessable and may expose activity patterns (e.g., “when was this record created?”).
- Clock problems: if the system clock jumps backwards or has low resolution, generators must handle it correctly (often via clock sequence; behavior varies by implementation).
- Sorting pitfalls: string sorting may look time-ordered, but true ordering depends on byte layout and how your platform stores GUIDs / UUIDs (some reorder bytes internally).
- Implementation differences: node source (MAC vs random), clock handling and monotonicity strategies vary by library and OS.
Technical description
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 structure (RFC 4122)
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 Validator and see for yourself what fields are available.
Format and structure
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).
Frequently Asked Questions
GUID / UUID v1 is a time-based identifier that combines a 60-bit timestamp (100-nanosecond intervals since October 15, 1582), a 14-bit clock sequence, and a 48-bit node identifier (historically a MAC address). This combination ensures uniqueness across distributed systems without central coordination.
Historically, yes. The node field in GUID / UUID v1 was typically the network card's MAC address, which could identify specific devices. Modern implementations often use a random node value instead, but this is implementation-dependent. You should not assume the node field is randomized. Always check your library's documentation.
No, GUID / UUID v1 is not formally deprecated in RFC 9562 or RFC 4122. It remains valid and is supported by most GUID / UUID libraries. However, it is widely considered a legacy format and is discouraged for new designs due to privacy and security concerns.
Partially. GUID / UUID v1 contains timestamp information, making it time-correlated. However, the timestamp fields are not in chronological order in the string representation, and sorting behavior depends on whether you sort by string or raw bytes. For reliable time-based sorting, use GUID / UUID v7 which has timestamp as a prefix.
The clock sequence is a 14-bit counter used to prevent duplicates when the system clock moves backward or when generating multiple GUIDs / UUIDs in rapid succession. It's incremented when clock issues are detected, helping maintain uniqueness even in edge cases like clock adjustments or high-frequency generation.
Yes, the timestamp is embedded in GUID / UUID v1 and can be extracted. However, the timestamp fields are split across different parts of the UUID (time_low, time_mid, time_hi_and_version), so extraction requires understanding the bit layout. Many GUID / UUID libraries provide utilities to extract v1 timestamps. Note that this is a privacy concern. Anyone can see when the GUID / UUID was created.
GUID / UUID v1 generators handle clock changes through the clock sequence field. If the clock moves backward or the resolution is too low, the generator increments the clock sequence. However, handling varies by implementation. Some may use random values, persist state to disk or use other strategies. Check your library's documentation for specific behavior.
GUID / UUID v1 uses October 15, 1582 as its epoch (the start of the Gregorian calendar). The timestamp is a 60-bit count of 100-nanosecond intervals since that date. This differs from Unix timestamps (which start from January 1, 1970) and provides sufficient range to represent dates far into the future.
Conclusion
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.
Learn more
These articles expand on related concepts, formats and practical considerations.