Generate time-ordered UUID v7 tokens (RFC 9562) and inspect existing UUIDs to extract timestamps and random bits.
The tool does two things. It generates UUID version 7 tokens, the RFC 9562 format that embeds the current Unix time in milliseconds in the first 48 bits, so tokens are practically unique and sort near creation order. It also inspects any UUID you paste and reports the version, variant, embedded timestamp, and the random bits filling the rest of the token. Everything runs locally; nothing is uploaded. The surprise: 'time-ordered' holds only to the millisecond. Two tokens minted in the same millisecond share a timestamp, and their random bits decide the order, unless the generator adds the monotonic counter methods from RFC 9562 section 6.2.
A concrete input and expected output from the current implementation.
Input
019fba9e-d800-7a1f-8012-3456789abcde
Expected output
Version: 7 (RFC 9562) Variant: RFC 4122 (leading bits 10) Timestamp: 2026-08-01 00:00:00.000 UTC Unix epoch: 1785542400000 ms rand_a (12 bits): 0xa1f rand_b (62 bits): 0x00123456789abcde
The first 48 bits are the Unix epoch in milliseconds: 0x019fba9ed800 equals 1785542400000, which is 2026-08-01 00:00:00.000 UTC. The '7' at the start of the third group is the version nibble, 'a1f' the 12-bit rand_a. The '8' starting the fourth group carries the variant bits (binary 10); the 14 bits left in that group (value 0x12) and the 48 bits of the fifth group (0x3456789abcde) form the 62-bit rand_b, shown zero-padded here as 0x00123456789abcde.
Generation reads the clock as Unix epoch milliseconds, stores it big-endian in the 48 most significant bits, sets the version nibble to 7 and the variant bits to 10, and fills the remaining 74 bits with random data (12-bit rand_a, 62-bit rand_b). RFC 9562 section 6.2 allows a generator to use part of that space for a monotonic counter so same-millisecond tokens sort in order. Output is the 8-4-4-4-12 hex string.
Inspection splits the 32 hex digits back into the same fields, confirms the version nibble is 7 and the variant bits are 10, then reads the first 48 bits as a big-endian millisecond count and converts it to a UTC date-time. It also reports rand_a and rand_b separately, so you can see which parts of the token are time and which are noise. Because the layout is fixed, extraction is exact and reversible.
For insert-heavy workloads, usually yes: time-ordered keys keep new rows clustered in the index and avoid the random insert positions that v4 keys cause. The tradeoffs: a v7 key reveals when it was created to the millisecond, and under heavy write concurrency the generator must handle same-millisecond ordering explicitly. Use v4 or a sequence when you want no time signal at all.
Only to the millisecond, and only as well as the generating machine's clock was set. The embedded time is the generator's UTC time at minting; it is not a verified or signed timestamp, and nothing in the token identifies the machine that made it. For audit-grade evidence you need a separate, externally verifiable timestamp.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.