The short answer
A UUID is a 128-bit identifier that different machines can generate independently and still be confident they will never clash — and the "version" number just tells you how those 128 bits were produced. UUID v1 is time-and-machine based (it embeds a timestamp and the network card's MAC address), v4 is purely random (the default choice for almost everything), and v5 is name-based and deterministic (the same input name always hashes to the same UUID via SHA-1). Two more matter today: v3 is the older MD5 twin of v5, and v7 — new in RFC 9562 (2024) — packs a Unix millisecond timestamp into the leading bits so the IDs sort by creation time, which is why it is now the recommended choice for database primary keys.
That is the summary an AI overview will give you. What it can't give you is the side-by-side of what each version leaks, whether it sorts, and the one-line rule for picking — so that's the rest of this page.
The comparison table
Every version is the same 128 bits in the same 8-4-4-12 hex format. Only the source of the bits changes — and that source decides everything about privacy, sortability, and fit.
| Version | Basis (how bits are made) | Deterministic? | Sortable by time? | Privacy | Collision model | Use it when |
|---|---|---|---|---|---|---|
| v1 | 60-bit timestamp + clock sequence + 48-bit MAC address | No | Weakly (bits are laid out low-field-first, so not lexicographic) | Leaks MAC address + creation time | Practically none (node + time + clock seq) | You need a legacy time-based ID and privacy is a non-issue |
| v3 | MD5 hash of (namespace UUID + name) | Yes — same input → same UUID | No | No machine data; reveals nothing beyond the name if guessable | None by design; identical inputs intentionally map to the same value | Interop with an existing system that already uses v3 |
| v4 | 122 random/pseudo-random bits | No | No | Leaks nothing (with a strong RNG) | ~2¹²² space; collision is astronomically unlikely | The default — general-purpose unique IDs |
| v5 | SHA-1 hash of (namespace UUID + name) | Yes — same input → same UUID | No | No machine data; reveals nothing beyond the name if guessable | None by design; deterministic mapping | You need reproducible IDs from a name (idempotency, dedup) |
| v7 | 48-bit Unix ms timestamp + random tail | No | Yes — leading time bits sort lexicographically | Reveals creation time, but not the MAC address | Random tail makes same-ms collisions astronomically unlikely | New database primary keys and time-ordered records |
The one-line decision rule: v4 by default, v7 for database keys, v5 for reproducible IDs — and reach for v1 only when you must, because it leaks your MAC address.
How the 128 bits differ
The version and variant bits sit in fixed positions, so you can read any UUID's version straight off its 13th hex digit. What changes between versions is only what fills the rest.
The amber block in every row is the fixed 4-bit version nibble. In v1 the timestamp comes first but is split so the values don't sort cleanly; in v4 almost everything is random; in v7 the timestamp leads, so v7 UUIDs march forward in order as you create them — the property that makes them index-friendly.
The three questions that pick the version
You rarely need to think about all seven versions. Three questions settle almost every real decision.
1. Do you need the same input to reproduce the same ID?
If yes, you want a name-based UUID: v5 (SHA-1) as the default, or v3 (MD5) only for compatibility with something that already emits v3. Determinism is the feature — feed the same namespace and name, get the same UUID on any machine, forever. This is how you build idempotent operations, deduplicate records, or derive a stable ID for an external key without storing a mapping table. If you don't need reproducibility, skip both.
2. Will this ID be a database primary key?
If yes, prefer v7. Random v4 keys scatter inserts across a B-tree index, fragmenting it and hurting write throughput and cache locality at scale. v7's leading timestamp means new rows append to the "end" of the index in roughly sequential order — the write pattern databases love — while still being globally unique and generatable without a central sequence. This is the single biggest reason v7 was added to RFC 9562. (See our deeper dive on UUIDs as database primary keys.)
3. Otherwise — is anything security- or privacy-sensitive?
Then use v4. It is the universal default: random, opaque, stateless, and supported everywhere. The only caveat is the random source. v4's guarantees evaporate if the generator is a weak, predictable PRNG — always use a cryptographically secure one for tokens, session IDs, or anything an attacker would love to guess. And avoid v1 here entirely: it stamps the generating machine's MAC address and the exact creation time into the value, a genuine privacy leak that has been used to de-anonymize documents.
Common misconceptions
"UUIDs are guaranteed unique." They are collision-resistant, not mathematically guaranteed. v4 relies on probability (see the collision-probability analysis), v1/v6/v7 rely on time plus randomness, and v3/v5 are deterministic by design. Uniqueness is overwhelmingly likely, not proven.
"v5 is more secure than v4." Different jobs. v5 is deterministic; v4 is unpredictable. A v5 UUID is trivially reproducible by anyone who knows the namespace and name, so it is not a secret. If you need an unguessable token, that is a job for v4 from a secure RNG — not v5.
"Higher version number means better." The versions are not a quality ladder. v7 is not "better than v4"; it is better for time-ordered keys. v4 remains the right default for opaque IDs, and a name-based v5 has no v-number equivalent that improves on it.
"UUID and GUID are different things." GUID is just Microsoft's name for the same 128-bit standard — the UUID vs GUID distinction is naming, not format. A .NET Guid and an RFC 9562 UUID are interchangeable on the wire.
Generating them in practice
Every mainstream language ships UUID support, though the version coverage varies — some standard libraries still only expose v1/v3/v4/v5 and need a small library for v7. Our guide to generating UUIDs across programming languages has the exact one-liners for Python, JavaScript, Go, Java, C#, and more. For quick one-offs, the generator above produces any version client-side, in your browser, with nothing sent to a server.
The bottom line
Pick by intent, not by version number:
- Reproducible from a name? → v5 (v3 only for legacy interop).
- Database primary key / time-ordered? → v7.
- Everything else / when in doubt? → v4, from a secure random source.
- v1? Only for legacy time-based needs where leaking a MAC address and timestamp is acceptable.
All of them are the same 128 bits in the same format — so you can always tell what you're holding by reading the version digit, and you can always generate the exact version you need for the job at hand.