UUIDs Explained: v4, v7, and When the Version Matters

One digit in the middle of the string tells you how the whole ID was made — random roll, timestamp, or a hash of a name. Sometimes that digit is trivia. Sometimes it’s the design.

Published October 31, 2026 · A Verystep guide

Illustration of many small ID cards each with a unique dot pattern, one card highlighted in amber above a database cylinder

A UUID is a 128-bit identifier written as 32 hex digits in 8-4-4-4-12 groups. The 13th hex digit is the version. Version 4 fills 122 bits with randomness, which is why collisions need quintillions of IDs before they become plausible — it’s the safe default for keys, tokens and filenames. Version 7, standardised by RFC 9562 in 2024, leads with a millisecond timestamp, so v7 IDs sort in creation order and behave far better as large database primary keys. The version matters in four cases: database keys at scale, deterministic IDs (v3/v5), information leakage (v1 exposes a MAC address, v7 exposes creation time), and security tokens, where the randomness matters more than the label.

Anatomy: 128 bits wearing a hyphenated coat

A UUID is a 128-bit value. Written out, it becomes 32 hexadecimal digits split into five groups — 8-4-4-4-12 — with hyphens between them, which is why the string you copy is 36 characters long. The textbook example looks like this: 550e8400-e29b-41d4-a716-446655440000. Nothing in that string names a server or a counter. Anyone, anywhere, can mint one without asking a registry — that is the whole point of the design.

Two spots in the string aren't random at all. The first digit of the third group — the 13th hex digit overall — is the version: a 4 in the example above. The first digit of the fourth group is the variant marker: in the standard layout it starts as 8, 9, a or b. Read those two digits and you can tell any UUID's recipe off the string itself.

v4: pure randomness, and why it holds up

Version 4 is the one the generator below makes, and the one most software reaches for by default. Apart from the 6 fixed marker bits, every bit is random: 122 bits of randomness drawn from a proper cryptographic random source — in your browser, that's the Web Crypto API.

People worry about collisions, and on paper they can happen. In practice the numbers are absurd. Getting to even a fifty-fifty chance of one collision needs roughly 2⁶¹ UUIDs — about 2.3 quintillion of them. Generate a billion per second and you're still decades from a coin flip. That's why two services can mint IDs independently, merge their databases later, and never find a clash.

v7: a timestamp at the front, randomness behind it

Version 7 is the new arrival. RFC 9562 standardised it in 2024, updating the original RFC 4122. A v7 UUID opens with a 48-bit Unix timestamp in milliseconds, then the version marker, then random bits. Because the time comes first, v7 values sort in roughly the order they were created — sort the strings and you've sorted the moments.

Illustration of scattered blocks on the left and blocks arranged in a rising staircase order under a clock on the right — Random IDs land anywhere. Time-ordered IDs line up — and databases notice the difference.

Why would anyone care about sort order? Databases do. A typical index stores keys in sorted order, so an auto-increment counter appends neatly at one end. Random v4 keys land all over the index, splitting pages and scattering related rows. V7 gets you counter-like locality without a counter: new rows cluster together, inserts run smoother, and "the latest thousand records" becomes a simple range at the end instead of a full scan. The trade: v7 reveals roughly when an ID was created. Sometimes that leak matters — more on that below.

The rest of the family, briefly

Version	How it's made	Where it fits
v1	Timestamp plus the machine's MAC address	Legacy systems. Sortable in theory, awkward in practice — and it exposes the hardware address of whatever made it
v3	MD5 hash of a namespace plus a name	The same name always gives the same UUID. Superseded by v5 for new work
v4	122 random bits	The default: database keys, tokens, filenames, anything that just needs to be unique
v5	SHA-1 hash of a namespace plus a name	Deterministic IDs derived from names — re-derivable anywhere, no storage needed
v7	Millisecond timestamp plus random bits	New database keys where insert order and index behaviour matter

Two special values exist too: the nil UUID of all zeros — the placeholder code reaches for when "no ID yet" needs to be a string — and the max UUID of all f digits. And v6? It's v1 reordered so it sorts properly, mostly a bridge for systems already built on v1.

When the version actually matters

Honestly? For a filename or a one-off token, it doesn't. Mint a v4 and move on. The version earns your attention in four situations.

Database keys at scale. If the UUID is a primary key in a large, fast-growing table, v7's ordering is worth real money in index health.

Deterministic IDs. If the same input name must always produce the same ID — deriving stable IDs for imported records, say — random versions can't help by design. That's the one job v3 and v5 exist for.

Leakage. V1 prints the maker's MAC address in every ID, and v7 prints its creation time. If IDs appear in public URLs or shared logs, ask yourself whether that leak is acceptable. V4 leaks nothing but the version marker.

Security tokens. A v4 from a cryptographic random generator is unguessable. The same format from a weak, seeded random function is not — the version digit guarantees the shape, not the quality of the randomness inside.

Choosing one, step by step

Ask what the ID is for. Just unique — a file, a request, a session? Stop here: v4.
Is it the primary key of a table that will grow large, where insert performance and chronological listing matter? Choose v7, provided your library and database support RFC 9562 values.
Must the ID be re-derivable from a name, identically, on any machine? Choose v5 with a fixed namespace.
Are you maintaining a system that already uses v1? Leave it alone unless the MAC-address exposure bothers you — then v6 or v7 is the migration path, not a weekend rewrite.
Whatever you pick, store and compare consistently: lowercase, hyphenated, never mixing "same ID, different formatting" variants in one column. More real-world bugs live in formatting mismatches than in collisions.

Generate v4 UUIDs in bulk

The Verystep UUID Generator mints version 4 UUIDs — the random default this guide recommends for most jobs — one at a time or in batches of up to 100, using your browser’s cryptographic random generator. Copy them all with one click. Nothing is sent to a server; the IDs are created on your machine.

Open the UUID Generator →

Last verified October 31, 2026 — structure, version markers and the v7 layout follow RFC 9562 (which updated RFC 4122), consistent with the reference table on the generator below.

Frequently asked questions

What’s the difference between UUID v4 and v7?

V4 is random: 122 of its 128 bits come from a random generator, so its values land in no order at all. V7 leads with a 48-bit millisecond timestamp and fills the rest randomly, so v7 values sort roughly in creation order. V7 is friendlier to database indexes; v4 reveals nothing about when it was made.

Can I tell a UUID’s version just by looking at it?

Yes. Find the third group of the string and read its first digit — that’s the version. A 4 means random, a 7 means time-ordered. The first digit of the fourth group is the variant marker: 8, 9, a or b in the standard layout.

Are v4 collisions really impossible?

Not impossible — just vanishingly unlikely. With 122 random bits, you’d need around 2.3 quintillion v4 UUIDs before the chance of even one collision reached fifty-fifty. In practice a v4 collision is never the failure that gets you; formatting bugs and reused IDs are far more common.

Should I switch my database primary keys from v4 to v7?

If the table is large or growing fast, v7 usually earns the switch: its time-ordered values append neatly in indexes instead of landing at random, and "latest records" queries get simpler. For small tables the difference is unmeasurable, and older libraries or databases may not support v7 yet — verify yours does before migrating.

Is a UUID a safe secret token?

A v4 UUID from a cryptographic random generator carries 122 unpredictable bits, which is a solid amount of entropy for a token. But the guarantee lives in the generator, not the format: a UUID built from a weak or seeded random function can be guessable despite looking identical. Never use v1 for secrets — it’s built from a timestamp and a hardware address.