UUID v1 Generator — Time-Based UUID
Generate UUID version 1 (time-based) UUIDs in bulk. Copy individual or all at once.
About UUID v1 Generator — Time-Based UUID
UUID v1 Generator creates time-based universally unique identifiers (UUID version 1) using the current timestamp and node identifier. UUID v1 encodes the creation time, making it useful for time-ordered record generation.
How to Use
- 1Click "Generate" to create one or more UUID v1 strings.
- 2Copy the generated UUID(s) and use them as unique identifiers in your database or application.
- 3Use the bulk generation option to create multiple UUIDs at once.
Features
- Time-based UUIDs that sort chronologically by creation time
- Generate multiple UUIDs at once in bulk
- Standard 8-4-4-4-12 UUID format compatible with all databases
- No server required — generated locally in the browser
How UUID v1 Is Structured
UUID v1 encodes the creation time directly into its bit layout, making it the original time-based UUID format defined in RFC 4122. Understanding its structure explains both its strengths and its limitations.
The 60-Bit Timestamp Field
UUID v1 uses a 60-bit timestamp field that counts 100-nanosecond intervals since October 15, 1582 (the start of the Gregorian calendar reform). This is stored across three fields in the UUID: time_low (32 bits), time_mid (16 bits), and time_hi_and_version (12 bits, with the top 4 bits reserved for the version number "1"). The 100-nanosecond precision means the same machine can generate up to 10 million non-colliding UUIDs per second from timing alone. In practice, most implementations also maintain a clock sequence counter that increments when the clock is adjusted backwards, preventing collisions across clock adjustments. The timestamp is stored in little-endian order within each field, which is why UUID v1 values do not sort chronologically by simple string comparison — the most significant bits of the timestamp are in the middle of the string.
The Node Identifier
The last 12 hex characters of a UUID v1 (48 bits) are the node identifier. In the original RFC 4122 specification, this was the MAC address of the network interface card, which guaranteed global uniqueness across machines. However, exposing MAC addresses in public-facing identifiers creates a privacy risk — an attacker can determine the network interface hardware that generated the UUID. Modern implementations often use a randomly generated 48-bit node identifier instead, which is compliant with RFC 4122 and preserves privacy. Browser-based generators like this one use a random node identifier because the Web Crypto API does not expose the MAC address of the device.
When to Use UUID v1
UUID v1 is suited for specific use cases where the embedded timestamp provides value. For most new applications, UUID v7 is a better choice, but UUID v1 remains relevant in certain contexts.
Time-Ordered Record Generation
UUID v1 values generated on the same machine within a short time window tend to cluster together when sorted. This can improve database insert performance compared to fully random UUIDs (v4) because sequential inserts are more likely to hit the same B-tree page, reducing page splits and index fragmentation. However, the clustering is imperfect because the timestamp bytes are not in the most-significant-first order within the UUID string. For better time-ordering with modern databases, UUID v7 solves this properly by placing the timestamp in the most significant bits so that lexicographic order matches chronological order.
Legacy System Compatibility
UUID v1 was the original time-based UUID standard and is widely supported in older systems, libraries, and databases. If you are integrating with an existing system that generates or expects UUID v1 values, this generator lets you create compatible test values. Apache Cassandra uses UUID v1 (called TimeUUID) as a native data type for time-series data, where the embedded timestamp enables time-range queries using the UUID column directly. If you are working with Cassandra or similar systems that natively support UUID v1, this tool provides correctly formatted values for testing. For new systems with no legacy constraints, prefer UUID v7 for its proper time-ordering and cleaner design.
FAQ
- What is the difference between UUID v1 and v4?
- UUID v1 is time-based and encodes the creation timestamp. UUID v4 is random — better for privacy but cannot be time-sorted.
- Is UUID v1 unique across different machines?
- UUID v1 uses a node identifier combined with timestamp. Collisions are extremely unlikely but theoretically possible.
- Can UUID v1 reveal sensitive information?
- Yes. UUID v1 embeds the timestamp of creation. If used as public-facing IDs, this can leak when records were created.
- Is UUID v1 safe to use in production systems?
- UUID v1 can be used in production but has privacy considerations: it embeds the generating machine's MAC address and the timestamp, which reveals when and where the UUID was created. This is generally acceptable for internal database keys where the data is not publicly visible. For public-facing identifiers (URLs, API tokens) or systems where privacy matters, UUID v4 (purely random) or UUID v7 (timestamp-ordered but without MAC address) are preferred.
- What does the timestamp in a UUID v1 represent?
- UUID v1 uses a 60-bit timestamp representing the number of 100-nanosecond intervals since October 15, 1582 (the start of the Gregorian calendar). This timestamp is split across three fields in the UUID structure (time_low, time_mid, time_hi_and_version). The timestamp-based structure means UUID v1s generated on the same machine are nearly sequential, which has database index locality benefits but also makes generation time predictable and traceable.
Found a bug or something not working as expected?
Report a bug →