How to Tell Which UUID Version You Have

Two systems both produce UUIDs. One’s identifiers sort chronologically and the other’s don’t, and until you know which version each is generating you can’t explain why an index is fragmenting on one table and not the other.

The version is written into the identifier itself, in a fixed position, and reading it takes seconds once you know where to look.

Where the version lives

A UUID is 32 hex digits in five hyphenated groups:

xxxxxxxx-xxxx-Vxxx-Nxxx-xxxxxxxxxxxx

The version is the first digit of the third group — the V. The variant is encoded in the first bits of the fourth group, the N, and for standard UUIDs it’s typically 8, 9, a or b.

So 018f1a2b-3c4d-7e8f-9012-3456789abcde is version 7, variant RFC 4122. No parsing library required.

What each version means in practice

Version 4 is random. 122 bits of randomness, no structure, no information leaked. It’s the default nearly everywhere and it’s a fine choice — except in one specific place.

Version 7 is time-ordered: a millisecond timestamp in the high bits, randomness in the rest. It looks random, it’s globally unique, and it sorts by creation time.

Version 1 embeds a timestamp and, in older implementations, the MAC address of the generating machine. That last part is why it fell out of favour.

The database consequence is the interesting one. A B-tree index on random v4 keys receives inserts scattered across the whole key space, which causes page splits and fragmentation and progressively worse insert performance on large tables. Time-ordered v7 keys append near the end of the index, which keeps inserts localised and the index compact.

That’s the main reason v7 exists, and the main reason to care which version your system generates.

Why people get stuck here

• Assuming all UUIDs are v4. Most are, and the ones that aren’t behave differently in ways that matter.
• Index fragmentation with no obvious cause. Random primary keys on a large table degrade gradually rather than failing.
• Unintended timestamp exposure. A v7 identifier in a public URL publishes when the record was created.
• Reading the wrong digit. The version is in the third group, not the first.

Common mistakes to avoid

• Using v4 as a clustered primary key on a table that grows large, then wondering why inserts slow down.
• Exposing v1 or v7 identifiers publicly without considering that they encode a creation time.
• Treating a UUID as a secret — it’s unique, not unguessable in the security sense, and v7’s timestamp portion is entirely predictable.
• Storing UUIDs as text when the database has a native 16-byte type, which quadruples index size.
• Assuming a UUID from an external system is v4 without checking.

How to do it with UUID Version Detector

The UUID Version Detector reads the version and decodes what it implies.

1. Paste the UUID, with or without hyphens.
2. Read the version digit — the first character of the third group.
3. If it’s v1 or v7, look at the decoded timestamp, which is information the identifier publishes.
4. Check the variant bits if you’re validating input rather than just inspecting it.

RFC 9562 is the current specification, and it’s where v7 is defined. Other developer tools are in the tools directory.

Frequently asked questions

Which UUID version should I use?

Version 4 for pure randomness with no ordering. Version 7 when you want random-looking identifiers that also sort by creation time, which is much kinder to database indexes.

Why does version 7 help database performance?

Because random v4 keys scatter inserts across a B-tree index, fragmenting it. Time-ordered v7 keys append near the end, keeping inserts localised.

Do UUIDs leak information?

Version 1 embeds a timestamp and, in older implementations, a MAC address. Version 7 embeds a timestamp deliberately. Version 4 leaks nothing beyond the quality of its randomness.

Final thought

Check the version before choosing a primary key type. It’s one digit, and it predicts how the index will behave three years from now.

Try the free UUID Version Detector