UUIDs Explained: v1 vs v4 vs v7 and When to Use Each

A UUID is a 128-bit label written as 32 hex digits in five groups — 8, 4, 4, 4 and 12 characters — designed so that anyone can mint one anywhere without asking a central authority. They identify rows, files, sessions and API keys across systems that never talk to each other.

1. v1: time plus machine

Version 1 embeds a timestamp and a node identifier, usually derived from the network card. IDs sort roughly by creation time, which databases love, but they leak when and where they were made — a privacy smell that pushed most new systems away from v1.

2. v4: pure randomness

Version 4 fills 122 of the 128 bits from a cryptographic random source, with four bits fixed to mark the version. Collision odds are absurdly small — generating a billion IDs per second for a century still leaves the chance of one duplicate far below hardware failure rates — but the randomness scatters database indexes, slowing inserts on huge tables.

3. v7: the modern default

Version 7 puts a millisecond timestamp first and fills the rest randomly, giving time-ordered IDs without leaking machine identity. New projects that need sortable, index-friendly identifiers should reach for v7; it is what our UUID generator produces alongside classic v4.

4. When not to use a UUID

Short human-facing codes, invoice numbers and anything users type by hand are better served by counters or compact encodings — UUIDs are long, unpronounceable and typo-prone. Never use any UUID as a secret: they are unique, not unguessable, since v1 and v7 contain timestamps and v4, while random, is often logged or exposed in URLs.