UUID Versions

A UUID is a 128-bit identifier written as 32 hex digits in 8-4-4-4-12 groups, standardised in RFC 9562. The version nibble tells you how it was made: v1 and v6 from a clock, v3 and v5 from a name hash, v4 from randomness, v7 from a Unix timestamp plus randomness — each with different ordering and privacy trade-offs.

端末内で処理

以下の解説は英語のみでご覧いただけます。

Two systems that have never met need to name a row, a request or a file without asking anybody. That is the problem UUIDs solve: generate an identifier from local information — a clock, random bits, a name — and the odds of anyone else generating the same value are small enough to plan around. No coordination service, no shared counter to race on, no central registry to consult.

The current standard is RFC 9562, published in May 2024 as the successor to RFC 4122, and its headline change is official status for two newer versions: v6 and v7. The version lives in the most significant nibble of the third group — the first hex digit after the second hyphen — and the variant bits open the fourth group. Reading those two digits tells you a UUID's provenance at a glance.

This guide explains each version's bit layout, what it is good at, and where its honesty ends — including the privacy cost of v1's embedded MAC address and the collision math behind v4. The generator linked below produces several versions locally, so you can inspect the pattern on your own machine.

Every layout below is easier to read from a real specimen — the UUID Generator produces v4 and v7 identifiers in your browser, and nothing it generates is logged or sent anywhere.

Identifiers travel inside tokens, too; the JWT structure guide shows where a jti claim carries a UUID and why the token around it is signed but not secret.

Anatomy: 128 bits in 36 characters

A UUID is 128 bits, canonically written as 32 lowercase hexadecimal digits in five hyphen-separated groups of 8-4-4-4-12 — 36 characters with the hyphens, 32 without. The layout is not decoration: specific bit ranges carry meaning. The four-bit version field occupies the top nibble of the third group, and the two-bit variant — which distinguishes RFC-style UUIDs from older Microsoft and legacy layouts — occupies the top bits of the fourth group, always reading 8, 9, a or b in hex.

Group	Example digits	Contents (shown for a v1)
1	614e4000	time_low — the least significant timestamp bits
2	26bc	time_mid — the middle timestamp bits
3	11ef	12 timestamp bits, then the 4-bit version — the 1 means v1
4	b17d	2-bit variant (binary 10), then 14 clock-sequence bits
5	0242ac120002	48 node bits — in v1, the generating machine's MAC address

Four versions, one glance

v1  614e4000-26bc-11ef-b17d-0242ac120002
v4  f7b17bde-5a0c-4174-8c95-407558615543
v6  1ec9414c-232a-6b00-b3c8-9e6bdeced846
v7  019b76da-a800-7c3e-8f2a-5b6c7d8e9f0a

Where to look

3rd group, 1st hex digit = version (1, 4, 6, 7 here)
4th group, 1st hex digit = variant (b, 8, b, 8 here)

v1 and v6: a clock and a MAC address

v1 builds the identifier from a 60-bit timestamp counting 100-nanosecond intervals since 15 October 1582 — the start of the Gregorian calendar — plus a clock-sequence counter and the machine's 48-bit MAC address. The timestamp is split non-obviously as time_low, time_mid, time_high, a field order chosen for a 1990s bit-packing convenience and later regretted. The MAC address is the privacy landmine: every v1 UUID reveals which hardware made it, which is why RFC 4122 already allowed substituting a random multicast node.

v6 is v1 with the field order corrected: the most significant timestamp bits move to the front, so v6 UUIDs sort chronologically when sorted as strings. Same clock, same node field, same privacy caveats — but far better database behaviour, which is the entire point of the reorder.

The same timestamp, two field orders

v1:  614e4000-26bc-11ef-b17d-0242ac120002
v6:  1ec9414c-232a-6b00-b3c8-9e6bdeced846

What sorts correctly in a string index

v6 — its timeHigh field leads, so lexicographic
order is chronological order. v1 leads with the
least significant bits and scatters instead.

v3 and v5: identity from a name

v3 and v5 derive the identifier from a namespace UUID and a name, hashed with MD5 (v3) or SHA-1 (v5). Same namespace, same name, same UUID — on every machine, forever. That determinism is the feature: derive stable identifiers from URLs, usernames or domain names without storing a mapping table, and regenerate them any time on any system.

The cost is the flip side of determinism: the identifier leaks information about the name. A v5 of a low-entropy name can be confirmed by simple guessing, and identical names produce identical identifiers on purpose. v5 supersedes v3 — SHA-1 over MD5 — and although RFC 9562 names no new name-based version, new designs that want both determinism and time-ordering usually move to v7 with the name stored alongside.

Deterministic: same input, same output

namespace: DNS   6ba7b810-9dad-11d1-80b4-00c04fd430c8
name:      python.org

v3  6fa459ea-ee8a-3ca4-894e-db77e160355e
v5  886313e1-3b8a-5372-9b90-0c9aee199e5d

Why it reproduces anywhere

hash(namespace bytes || "python.org") with the version
(3 or 5) and variant (binary 10) written into fixed
bit positions — the same computation, bit for bit.

v4: 122 random bits and what that buys

v4 sets 122 bits from a cryptographically secure random generator; only the version and variant nibbles are fixed. Collision odds follow the birthday bound: after generating n values, the chance of any duplicate is roughly n²/2¹²³. You would need around 2^61 UUIDs — about 2.3 quintillion — for a coin-flip chance of a single collision. When duplicates do surface in practice, the cause is almost always broken randomness — a weak seed, reused PRNG state, a hardware fault — never the odds themselves.

Randomness is also v4's weakness as a database key: completely unordered values land in random B-tree pages, fragmenting indexes and exhausting write caches at scale. That complaint is precisely what v6 and v7 were standardised to fix, and the reason many ORMs and distributed databases now steer new tables toward v7.

v7: Unix milliseconds plus randomness

v7 is the modern default candidate: 48 bits of Unix timestamp in milliseconds, then 12 plus 62 bits of random payload. The leading timestamp makes v7 UUIDs sortable as strings — index-friendly in exactly the databases that store them — while the 74 random bits keep collision odds effectively at v4's level. It needs no MAC address, no 1582 epoch, and no calendar conversions.

Within the same millisecond, RFC 9562 describes a monotonic counter in the rand_a field so identifiers created in rapid succession still increase — a property primary keys care about even more than raw uniqueness. The timestamp is also legible: it reads as 2026, not as a count of 100-nanosecond ticks from 1582, which makes v7 pleasant to eyeball in logs and query results.

Time-ordered by construction

2026-01-01T00:00:00Z  019b76da-a800-7c3e-8f2a-5b6c7d8e9f0a
2026-01-01T00:00:01Z  019b76da-abe8-9d41-8c2f-4a5b6c7d8e9f

Sorted as strings, sorted in time

019b76da-a800-… < 019b76da-abe8-…

lexicographic order matches chronology,
and the top 48 bits are a Unix ms timestamp.

Choosing a version, honestly

For new work: v7 when identifiers should sort by time or live in a database index; v4 otherwise — both need no coordination and leak nothing about their origin. v5 earns its keep when the identifier must be reproducible from a name. v1 and v6 remain supported but leak hardware identity unless the generator randomises the node field, and v3 is MD5 legacy carried forward for compatibility. None of the versions are secret, and none of them anonymise data: a UUID is a name, not a credential.

Version	Source of bits	String-sortable	Watch out for
v1	Gregorian timestamp + clock seq + MAC node	No	MAC address leakage
v3	MD5 of namespace + name	No	MD5 legacy; names are guessable
v4	122 random bits	No	Random insert order fragments indexes
v5	SHA-1 of namespace + name	No	Deterministic — names confirmable by guessing
v6	v1 reordered for sortability	Yes	Same MAC caveat as v1
v7	Unix ms timestamp + 74 random bits	Yes	Same-millisecond ties without a monotonic counter

Frequently asked questions

Do the UUIDs generated on this site get recorded anywhere?

No. The generator creates identifiers with your browser's own randomness API inside the tab — there is no upload step and no server-side log, because the code never sends a request. You can watch the Network panel stay silent while it works, and the site's Content-Security-Policy blocks outbound connections for the page's entire lifetime.

Can two UUIDs collide in practice?

For v4, the birthday bound puts a coin-flip chance of one duplicate at around 2^61 generated values — roughly 2.3 quintillion. Real collisions almost always indicate broken randomness rather than bad luck: a weak seed, reused PRNG state, or a hardware RNG fault. v3 and v5 'collide' deliberately — the same name in the same namespace yields the same UUID by design.

Why do some UUIDs sort badly as database primary keys?

Random versions (v4) scatter new rows across a B-tree index, writing to unpredictable pages and thrashing cache as the table grows. Time-ordered versions (v6, v7) append near the right edge of the index instead. If you are committed to v4 keys, the standard remedies are a separate time-ordered clustering column or moving new rows to v7.

Is a UUID secret or anonymous?

Neither. A UUID is an identifier, not a credential: it carries no proof of who holds it, and a v1 even broadcasts the generating machine's MAC address unless the node field was randomised. Treat UUIDs as names — safe to log, useful to correlate — and put authentication and authorisation in mechanisms that can actually verify something.

What is the difference between a GUID and a UUID?

They name the same 128-bit identifier family; GUID is Microsoft's term. The technical difference lives in the variant bits at the start of the fourth group, which distinguish RFC-style UUIDs (binary 10 — first hex digit 8, 9, a or b) from older Microsoft and legacy layouts. Modern GUIDs are generated as RFC variants, which is why the two terms are used interchangeably in most documentation.

Why does the v1 timestamp start in 1582?

The 60-bit counter ticks in 100-nanosecond intervals from the Gregorian calendar reform on 15 October 1582 — chosen so the counter began far enough in the past that it will not overflow for millennia. The price is legibility: a v1 timestamp is meaningless without a converter. v7's Unix milliseconds were chosen partly because they read directly as dates.

ToolsByUs team · How we check our tools

UUID Versions explained