UUID v7 Generator

UUID version 7 is a 128-bit identifier layout standardized by RFC 9562. Its most significant 48 bits contain an unsigned count of milliseconds since 1970-01-01 00:00:00 UTC, excluding leap seconds. The version field consumes four bits, the RFC variant consumes two, and 74 remaining bits provide randomness or carefully defined monotonic fields plus randomness.

Putting time first makes UUID v7 values sortable as opaque bytes and as standard hyphenated text. Values created in later milliseconds compare after earlier values without rearranging the fields. That property is useful for database indexes, event streams, logs, and other systems that want decentralized identifiers but prefer chronological locality over the random insertion pattern of UUID v4.

UUID v7 does not replace a timestamp column. The embedded time describes UUID generation, may reflect an inaccurate or deliberately altered system clock, has only millisecond precision in its standard leading field, and lacks business meaning such as “created after validation.” Keep explicit application timestamps whenever the distinction matters.

A basic conforming UUID v7 implementation may fill all 74 non-version and non-variant payload bits with fresh random data. The timestamp makes values ordered across different milliseconds, but random suffixes do not guarantee that two IDs generated during the same millisecond appear in creation order. Calling every UUID v7 generator “strictly monotonic” is therefore inaccurate.

RFC 9562 describes optional methods for additional monotonicity. An implementation can put a fixed-length counter immediately after the timestamp, use a randomly seeded monotonic value, or replace up to 12 leading random bits with additional clock precision. Counters require state, clock rollback handling, overflow behavior, and enough capacity for the maximum generation rate. A generator must not knowingly return duplicates after counter rollover.

LiveParse keeps state inside each requested batch. It seeds a fixed 14-bit counter from the browser cryptography source, places that counter immediately after the timestamp across rand_a and the first two available rand_b bits, and fills the remaining 60 bits with fresh cryptographic randomness for every value. The counter advances when multiple values use the same effective millisecond. If the clock would move backward during that batch, the generator retains the last effective millisecond before advancing the counter. The output is therefore lexically increasing within that one batch. Separate page loads, tabs, devices, and application processes do not share that state, so this page does not claim a global total order.

Remove presentation syntax and read the first twelve hexadecimal digits as one unsigned 48-bit integer. That integer is Unix milliseconds. For the RFC vector, 017f22e279b0 equals 1645557742000. Converting that value to UTC produces 2022-02-22T19:22:22.000Z.

The LiveParse inspector performs that extraction only after parsing the complete UUID, identifying the RFC variant, and finding version 7. A string that merely begins with twelve hex digits is not enough. Strict input mode requires the ordinary 8-4-4-4-12 text form; normalize mode can unwrap braces, a case-insensitive urn:uuid: prefix, or a compact 32-digit value before inspection.

Extracted time is evidence about the bits, not proof about the event that produced them. A generator can have a wrong clock, an application can import an old ID later, and an attacker can construct any UUID bits. Do not authorize, bill, expire, or order security-sensitive events solely from an untrusted UUID timestamp.