UUIDs Explained

A UUID (Universally Unique Identifier), also called a GUID on Microsoft platforms, is a 128-bit value used to label information so it can be identified without a central authority. Because they can be generated independently on any machine with a negligible chance of collision, UUIDs are everywhere: database keys, distributed systems, file names, API request IDs and message IDs.

Here’s a fresh one, generated in your browser:

Anatomy of a UUID

A UUID is 128 bits, written as 32 hexadecimal digits in five hyphen-separated groups: 8-4-4-4-12.

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

• M (13th hex digit) is the version — 1, 3, 4, 5 or 7.
• N (17th hex digit) encodes the variant — for standard UUIDs it is one of 8, 9, a, b.

UUID versions

Version	Based on	Deterministic?	Sortable?	Best for
v1	Timestamp + node (MAC)	No	Partly	Legacy systems; when time/node encoding is required
v3	MD5 of namespace + name	Yes	No	Stable IDs from a name, MD5-compatible
v4	Random	No	No	General-purpose default
v5	SHA-1 of namespace + name	Yes	No	Stable IDs from a name (preferred over v3)
v7	Unix-ms timestamp + random	No	Yes	Database primary keys, time-ordered IDs
nil / max	All zeros / all ones	—	—	Sentinel “no value” markers

v4 — random

122 random bits and 6 fixed bits (version + variant). The simplest and most common choice. Generate it from a cryptographically secure RNG (browsers expose crypto.randomUUID()).

v7 — time-ordered

Introduced in RFC 9562. The first 48 bits are a Unix millisecond timestamp, so v7 UUIDs sort in creation order — much better B-tree index locality than v4 when used as a primary key, while the rest stays random for uniqueness. For new systems that store UUIDs in a database, v7 is usually the best pick.

v3 & v5 — name-based (deterministic)

These hash a namespace UUID plus a name string: the same inputs always produce the same UUID. v5 uses SHA-1 and is preferred; v3 uses MD5 and exists mainly for compatibility. Standard namespaces are defined for DNS, URL, OID and X.500 names. Use these when you need a stable ID derived from existing data (e.g. a URL) rather than a random one.

v1 — time + node

Encodes a 60-bit timestamp (100-ns intervals since 1582) and a node identifier, historically the machine’s MAC address. Because it can leak the generating machine and time, most implementations now randomise the node. Prefer v7 for new time-based needs.

Benefits

• Decentralised — generate IDs anywhere with no coordination or central sequence.
• Collision-resistant — 122 random bits make duplicates practically impossible.
• Merge-friendly — safe to combine records from multiple sources or databases.
• Opaque — reveal no count or ordering (except v1/v7 by design).

Drawbacks & trade-offs

• Size — 128 bits (36 text chars) vs a 32/64-bit integer; larger keys and indexes.
• Index locality — random v4 keys scatter across a B-tree, hurting insert performance; v7 fixes this.
• Not human-friendly — hard to read, type or communicate verbally.
• Not secrets — never treat a UUID as unguessable security material.

Standards & references

• RFC 9562 — the current UUID specification (obsoletes RFC 4122); defines v1–v8, nil and max.
• RFC 4122 — the original UUID specification.
• MDN: crypto.randomUUID() — native v4 generation in the browser.

Try it

Generate any version in your browser (nothing is uploaded) with the CodingSetu UUID tools linked below.