UUID versions, explained: which one do you want?
7 Oct 2026 · Security · 6 min read
A UUID looks like this: f47ac10b-58cc-4372-a567-0e02b2c3d479. Thirty-two hexadecimal digits in five groups, and somewhere in the middle a single digit that says which version it is — here, the 4 at the start of the third group. That one digit changes what the other 31 digits mean, and picking the wrong version for your use case can quietly cause real problems: leaked timestamps, leaked machine addresses, or identifiers that don't sort the way you assumed.
This article explains what a UUID is, what the common versions do differently, and how to choose. Spoiler: for most people, most of the time, the answer is version 4 — but it's worth knowing why, and when the answer is different.
What a UUID actually is
A UUID (universally unique identifier) is a 128-bit number, conventionally written as 32 hex digits in an 8-4-4-4-12 grouping. The point of the format is decentralised uniqueness: anyone, anywhere, can generate an identifier without asking a central authority, and the chance of two people generating the same one is negligible. No database sequence, no coordination, no single point of failure.
The format reserves a few bits for metadata. Four bits (one hex digit) hold the version — which generation method was used. Two bits hold the variant, which identifies the layout standard (for the UUIDs you'll meet, the variant is always the one starting with binary 10, i.e. the hex digit is 8, 9, a or b in that position). The remaining 122 bits are the payload, and their meaning depends on the version.
You can read a UUID's version at a glance: look at the first character of the third group. f47ac10b-58cc-4372-... is version 4. ...-58cc-1372-... would be version 1.
The versions you'll actually meet
Version 1: timestamp + machine address. A v1 UUID embeds the current time (100-nanosecond intervals since 1582, charmingly) and the generating machine's MAC address, plus a random clock sequence. The upside: v1 UUIDs are roughly time-ordered, which databases love — new rows sort near each other, keeping indexes efficient. The downside is privacy: the UUID leaks when it was created and which network card created it. That was an acceptable trade-off in the 1990s; today it's a fingerprinting risk, which is why v1 has fallen out of favour for anything user-facing.
Version 4: pure random. All 122 payload bits come from a random number generator. There's no timestamp, no machine address, nothing to decode — just 122 bits of randomness, which is what makes collisions astronomically unlikely. This is the default "just give me a unique ID" choice, and it's what most generators (including the UUID Generator on this site) produce. If you don't have a specific reason to want another version, you want v4.
Version 7: timestamp-ordered random. The newcomer, standardised in 2024. A v7 UUID puts a Unix timestamp in milliseconds in the high bits and fills the rest with randomness. You get the best of both worlds: identifiers that sort by creation time (great for database primary keys) without leaking a MAC address, and with enough randomness that two generated in the same millisecond still differ. If you're designing a new system today and you want sortable IDs, v7 is the modern answer.
Versions 3 and 5: name-based. These hash a namespace plus a name (MD5 for v3, SHA-1 for v5) to produce a deterministic UUID: the same name always yields the same UUID. Useful when you need stable identifiers derived from existing data — but note they use older hash functions, and determinism means anyone who knows the name can reproduce the UUID, so they're identifiers, not secrets.
| Version | Built from | Sortable by time? | Leaks info? | Reach for it when… |
|---|---|---|---|---|
| v1 | Timestamp + MAC address | Yes | Yes — time and machine | Legacy systems that already use it |
| v4 | 122 random bits | No | No | You just need a unique ID (the default) |
| v7 | Timestamp + random bits | Yes | Only coarse time | New systems wanting sortable IDs |
| v3 / v5 | Hash of namespace + name | No | No (but reproducible) | You need the same ID from the same name |
How unique is "unique"?
For v4, the collision maths is reassuring. With 122 random bits, you'd need to generate about 261 UUIDs — roughly 2.3 billion billion — before reaching even a 50% chance of a single collision (that's the birthday paradox at work). To put it concretely: if you generated a billion UUIDs per second, you'd need about 70 years to reach a coin-flip chance of one duplicate. In practice, v4 collisions don't happen.
But there's a crucial qualifier: this assumes the random bits are actually random. A v4 UUID from a weak generator — seeded with the time of day, say — can collide far more often than the maths promises, and worse, can be predictable. "Random" in the UUID spec means cryptographically secure randomness: crypto.getRandomValues() or crypto.randomUUID() in the browser, your operating system's CSPRNG anywhere else. Never Math.random(), which is predictable by design.
Common mistakes
- Using UUIDs as secrets. A v4 UUID has 122 bits of entropy, which sounds like plenty for a token — and it is, if generated with a CSPRNG and treated as opaque. But UUIDs get logged, cached and shared in ways secrets shouldn't be. For session tokens and API keys, generate dedicated random tokens and keep them out of logs.
- Assuming v4 UUIDs sort by creation time. They don't — they're random. If your database pages by "latest first" on a v4 primary key, you'll get nonsense ordering. That's the exact problem v7 solves.
- Exposing v1 UUIDs to users. Every v1 UUID you hand out carries your server's MAC address and a precise timestamp. It's a small leak, but it's a leak, and there's rarely a reason to accept it in new code.
- Rolling your own format. "I'll just use a timestamp plus a counter" recreates the coordination problem UUIDs were invented to avoid. Use the standard.
Where you'll meet UUIDs in the wild
Once you know what to look for, UUIDs turn up everywhere. Databases use them as primary keys when rows are created on many machines at once — think of a mobile app that works offline and syncs later. Each phone generates IDs locally without consulting a server, and the randomness of v4 guarantees they won't collide when the data merges. File upload services name stored files with UUIDs so two users uploading photo.jpg never overwrite each other. Distributed tracing systems tag each request with a UUID so a single user action can be followed across a dozen microservices. Payment systems use them as idempotency keys: send the same key twice and the system knows it's a retry, not a double charge. And if you've ever browsed a Windows registry or a Bluetooth specification, you've seen UUIDs doing quiet structural work. They're infrastructure — invisible when they work, which is almost always.
The short answer
If you're naming things that have no name yet — database rows, uploaded files, idempotency keys, distributed events — generate a version 4 UUID from a cryptographically secure source and move on. If you're building a new database and want your primary keys to sort by creation time, look at version 7. If you need the same input to always produce the same identifier, that's version 5. Everything else is a special case you'll know when you meet it.
And whatever version you choose, generate it properly: the UUID Generator uses your browser's secure random generator (preferring crypto.randomUUID() with a correct manual v4 fallback), entirely on your device.