What is a UUID Version 1?
UUID Version 1 is a time-based identifier defined in RFC 9562 (and its predecessor RFC 4122). It generates a 128-bit value by combining three components: a 60-bit timestamp representing 100-nanosecond intervals since the UUID epoch (October 15, 1582, 00:00:00 UTC), a 14-bit clock sequence to avoid duplicates when the clock is adjusted, and a 48-bit node identifier that traditionally represents the generating machine's network MAC address.
The UUID epoch of October 15, 1582, was chosen because it marks the date of the Gregorian calendar reform. This historical anchor gives UUID v1 an enormous timestamp range — enough to represent dates well into the future without overflow.
How UUID v1 is Generated
The generation process for UUID v1 follows a precise algorithm:
- Obtain the current timestamp — The system clock is read and converted to 100-nanosecond intervals since the UUID epoch. In JavaScript,
Date.now()provides millisecond precision, which is then multiplied by 10,000 and offset by the epoch difference (122,192,928,000,000,000 intervals between the Gregorian epoch and Unix epoch). - Set the clock sequence — A 14-bit value that increments when the system clock is set backward or the node ID changes. This prevents duplicate UUIDs when timestamps repeat. In this browser-based generator, the clock sequence is randomized per generation for simplicity.
- Determine the node identifier — Traditionally the 48-bit IEEE 802 MAC address of the generating machine. Since browsers cannot access MAC addresses, this generator uses a random 48-bit value with the multicast bit set (bit 0 of the first octet = 1), as explicitly permitted by RFC 9562 Section 6.10.
- Assemble the UUID — The timestamp is split across three fields (time_low, time_mid, time_hi_and_version), the version nibble is set to
0x1, the variant bits are set to0b10, and all fields are packed into the 128-bit structure.
UUID v1 Byte Structure
The 128 bits of a UUID v1 are organized as follows:
| Field | Bits | Bytes | Description |
|---|---|---|---|
| time_low | 0–31 | 0–3 | Low 32 bits of the timestamp |
| time_mid | 32–47 | 4–5 | Middle 16 bits of the timestamp |
| time_hi_and_version | 48–63 | 6–7 | High 12 bits of timestamp + 4-bit version (0001) |
| clock_seq_hi_and_variant | 64–71 | 8 | High 6 bits of clock sequence + 2-bit variant (10) |
| clock_seq_low | 72–79 | 9 | Low 8 bits of clock sequence |
| node | 80–127 | 10–15 | 48-bit node identifier (MAC or random) |
Notice that the timestamp is split non-contiguously: the least significant bits (time_low) come first in the UUID string. This means UUID v1 strings do not sort chronologically by default — a key difference from UUID v7, which places the timestamp in the most significant bits for natural sorting.
When to Use UUID v1
UUID v1 is well-suited for scenarios where you need to extract the creation time from an identifier after the fact. Common use cases include:
- Audit trails and compliance logs — The embedded timestamp lets you determine when a record was created without relying on a separate column.
- Legacy system integration — Many enterprise systems, including Apache Cassandra's default TimeUUID type, expect UUID v1 format.
- Distributed event ordering — While not perfectly sortable as strings, the timestamp can be extracted and compared programmatically for loose chronological ordering.
Avoid UUID v1 when privacy is a concern (the timestamp reveals creation time) or when you need efficient database index performance with standard B-tree indexes (use UUID v7 instead).
Privacy Considerations
UUID v1 inherently encodes the creation timestamp, which can reveal when an entity was created. In the original specification, the node field contained the generating machine's MAC address, which could theoretically be used to identify the hardware. This generator mitigates the MAC concern by using random node values, but the timestamp remains embedded. If creation time is sensitive information, consider using UUID v4 (fully random) instead.
Frequently Asked Questions
What is a UUID Version 1?
A UUID Version 1 is a time-based universally unique identifier generated from a 60-bit timestamp, a 14-bit clock sequence, and a 48-bit node identifier. The timestamp measures 100-nanosecond intervals since October 15, 1582, giving it both uniqueness and time-traceability.
Does UUID v1 expose my MAC address?
Historically, UUID v1 used the network interface MAC address as the node field. This generator uses a random node with the multicast bit set, as permitted by RFC 9562 Section 6.10, so no hardware information is exposed.
Are UUID v1 values sortable?
UUID v1 contains a timestamp, but the bytes are not arranged in chronological order in the standard string representation. The time_low field comes first, which changes most rapidly. For truly time-sortable UUIDs, consider UUID v7, which places the timestamp in the most significant bits.
When should I use UUID v1 instead of v4?
Use UUID v1 when you need to extract creation timestamps from identifiers, when working with legacy systems that expect v1 format (like Apache Cassandra's TimeUUID), or when you want partial chronological ordering. For general purpose use where privacy matters, UUID v4 is simpler and safer.
Can two UUID v1 values collide?
UUID v1 collisions are extremely unlikely. The combination of a high-resolution timestamp (100-nanosecond precision), a random clock sequence, and a unique node identifier makes duplicates virtually impossible in normal operation, even across distributed systems.