Two very different 128 bits
A UUIDv1 encodes the MAC address and a timestamp; a UUIDv4 is 122 random bits (6 bits go to the version/variant markers). Both render as 36 characters like 550e8400-e29b-41d4-a716-446655440000 — the third group's leading digit (1 or 4) tells you which you have.
Why v1 fell out of favor
- Privacy: v1 leaks the generating machine's MAC address — which is why modern implementations randomize it, which removes v1's only ordering guarantee.
- Collisions across nodes: v1 uniqueness depends on correct clock discipline and unique MACs; virtualized fleets have violated both.
- Index behavior: timestamp-prefixed v1s insert sequentially into B-trees (the good part), but with the privacy fixes they're no better than v4 — and if you want orderability, ULIDs or UUIDv7 do it explicitly.
Why v4 is the default
Random v4 needs no coordination: any node generates IDs that are unique with overwhelming probability. Collision math: after generating a billion v4s, the chance any two match is ~10-18 — you should worry about almost anything else first. The trade-off: random IDs scatter across B-tree indexes, which matters at very large scale (that's what v7/ULID solve).
Neither is a security token
A UUID is an identifier, not a capability. v4's 122 random bits resist guessing, but v1 is predictable (timestamp + MAC), and neither was designed as an access token. For password resets, session IDs, or "unguessable links," use a CSPRNG with ≥ 128 bits (crypto.randomUUID or random bytes hex) and treat secrecy as a design requirement, not a UUID property.
Practical guidance
| Need | Reach for |
|---|---|
| General-purpose ID, no ordering | UUIDv4 |
| Sortable, time-ordered IDs in DBs | UUIDv7 or ULID |
| Deterministic ID from a name | UUIDv3/v5 (namespace hash) |
| Secret token | crypto random 32+ bytes, not a UUID |
Generate v4s (and other versions) in bulk, client-side, in the UUID Generator.