UUID Generator & Parser

Generate UUIDs (v1, v4, v5, v7) and parse existing UUIDs to inspect version and timestamp.

Tested tool guide Tested browser tools Checked August 16, 2026

What UUID Generator & Parser does, with a checked example

Every UUID carries its own ID card in two fixed positions: the 13th hex character declares the version and the 17th declares the variant. This page generates UUIDs in versions 1, 4, 5, and 7, and when you paste in any UUID it reads those markers, unpacks the timestamp hidden inside v1 and v7, and reports the fields that version defines. Two things usually surprise people: a v5 UUID is a one-way hash, so the same namespace-plus-name always reproduces the same string, while a v4 is pure randomness; and v1 time counts 100-nanosecond ticks from 1582-10-15, not the Unix epoch.

Worked example

A concrete input and expected output from the current implementation.

Input

B4CC8000-A838-11EE-83E5-3C2E1F0A9B87

Expected output

Version 1 (time-based); variant 10xx (standard); timestamp 2024-01-01 00:00:00.0000000 UTC; clock sequence 0x3E5; node 3C:2E:1F:0A:9B:87

The 13th character is 1, so this is version 1. Its three time fields (B4CC8000, A838, 1EE) reassemble to 139,233,600,000,000,000 ticks of 100 nanoseconds since 1582-10-15; subtracting the 122,192,928,000,000,000-tick offset to the Unix epoch leaves 1,704,067,200 seconds, which is 2024-01-01 00:00:00 UTC exactly.

How the result is produced

Reading the version and variant

The version is the high nibble of the 7th octet, which is the 13th hex character; the variant is the high 2 bits of the 9th octet, the 17th character, which for standard UUIDs is always 8, 9, a, or b. The parser first checks the shape - 32 hex digits, case-insensitive, with or without the four hyphens - then reports version, variant, and the fields that version defines.

Where the timestamp comes from

In v1, the time_low, time_mid, and time_high fields reassemble into a 60-bit count of 100-nanosecond intervals since 1582-10-15 00:00:00 UTC; the page subtracts the fixed Gregorian offset (0x01B21DD213814000 ticks) and divides by 10,000,000 to display a UTC date. In v7, the first 48 bits are a Unix millisecond timestamp, so no conversion is needed. Versions 4 and 5 contain no timestamp at all.

Good uses

Generate v4 UUIDs for database primary keys or API identifiers: values that carry no structure, need no coordination with a server, and are practically collision-free.
Generate v7 UUIDs for event logs, message queues, or time-series keys - the leading 48 bits are the Unix millisecond timestamp, so lexicographic order of the strings equals chronological order.
Paste a UUID found in a ticket, database, or API response to learn its version and variant, recover the exact creation time of a v1 or v7, and spot a nil UUID (all zeros) stored by mistake.

Limits and checks

A v1 timestamp is not Unix time. It counts 100-nanosecond ticks since 1582-10-15 00:00:00 UTC, so the page does the conversion - but a v1 minted before 1970 will legitimately show a pre-1970 date.
The node field of a v1 UUID is not necessarily the MAC address of the generating machine. RFC 9562 permits a random node and many generators use one, so do not treat that field as identifying hardware.
v5 is deterministic but namespaced: the same name under the DNS namespace and the URL namespace yields different UUIDs. The hash is one-way, so a v5 UUID can never be reversed back into its input name.

Common questions

Are v4 UUIDs unique, or can two ever collide?

No mechanism guarantees it, but in practice collisions never happen. A v4 has 122 random bits - about 5.3 x 10^36 possible values - and by the birthday bound you would need roughly 2^61 (about 2.3 x 10^18) UUIDs before a 50 percent chance of any collision appears, so ordinary use is safe.

Why is the timestamp in my v1 UUID several centuries off?

The raw count starts in the 16th century: v1 counts 100-nanosecond intervals since 1582-10-15 00:00:00 UTC, not the Unix epoch of 1970. A naive conversion lands centuries off target, which is why the page applies the 122,192,928,000,000,000-tick offset before showing the date. Today's v1 UUIDs parse to today's date.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.