Anatomy of a v4 UUID
Thirty-two hex digits as 8-4-4-4-12. In version 4, all but six bits are random: the third group starts with 4 (the version) and the fourth group starts with 8, 9, a, or b (the variant). That leaves 122 random bits — about 5.3 × 10³⁶ possible values — drawn here from crypto.getRandomValues(), the same source cryptographic keys use.
Will two ever collide?
Generate a billion UUIDs per second for a century and the probability of a single collision stays around 50% — for any real system, the answer is no. That's why v4 UUIDs safely serve as database keys, request IDs, and filenames without coordination between machines. (If you need IDs that sort by creation time, look at UUIDv7 or ULID — randomness is v4's feature and its only drawback.)
Frequently asked questions
Are these UUIDs truly unique?
Statistically yes: 122 random bits make collisions so improbable that generating billions per second for decades still leaves the odds negligible. No registry or coordination needed.
What's the difference between UUID versions?
v1 embeds timestamp and MAC address (leaky), v4 is pure random (this page), v5 is deterministic from a name+namespace hash, and v7 is time-ordered random — the modern pick for database keys that should sort by insertion.
Are v4 UUIDs safe to expose in URLs?
Yes — they reveal nothing about the record, the server, or the count of items (unlike sequential IDs). They're unguessable, though authorization checks still belong on every endpoint.
Uppercase or lowercase?
The RFC outputs lowercase and treats comparisons as case-insensitive. Store and emit lowercase (as generated here) and accept either on input.