Security
Generate UUIDs
A v4 UUID carries 122 random bits, so two independently generated values effectively never collide. The randomness comes from crypto.getRandomValues, not Math.random — the latter is predictable enough to be a real problem for identifiers.
Press Generate…
How to use it
- Pick how many you need.
- Tick uppercase or “no hyphens” to match your database column.
- Press Generate.
- Copy the whole block at once.
Versions are not interchangeable
v1 embeds a timestamp and a node identifier, which leaks when and where an ID was minted and makes IDs guessable in sequence. v4 is 122 random bits carrying no embedded information. v7, standardised recently, puts a millisecond timestamp first and randomness after, so IDs sort by creation time while staying unguessable. Choosing between them is an architectural decision, not a formatting preference.
Random keys and index fragmentation
A v4 primary key means every insert lands at a random point in the B-tree index, splitting pages and bloating the table over time. Time-ordered IDs such as ULID or v7 avoid this because new rows always append near the end. The trade-off is that the time prefix is visible to anyone holding the ID — worth stating explicitly rather than discovering during a privacy review.
Choosing a version when the IDs go into a database
UUIDv4 is 122 random bits and sorts meaninglessly, which is fine for a public identifier and bad for a primary key: every insert lands at a random point in the B-tree, and indexes fragment. UUIDv7 puts a millisecond timestamp in the high bits, so new rows append to the end of the index instead of scattering.
If the database is MySQL with a clustered primary key, that difference is worth measuring before choosing: sequential inserts are typically several times faster than random ones once the table no longer fits in memory.
Frequently asked questions
Are these safe as database keys?
As random identifiers, yes. They are unguessable, which makes them suitable for public-facing IDs. They are not sequential, so they fragment B-tree indexes more than an auto-increment integer — a known trade-off, not a bug.
What is the difference between v1 and v4?
v1 embeds a timestamp and the machine's MAC address, which leaks both when and where an ID was minted. v4 is pure randomness with no embedded information. Unless you need sortable IDs, use v4.
Can two generated UUIDs collide?
The odds are about 1 in 2^122 per pair. You would need to generate a billion UUIDs per second for roughly a century before a collision became likely.
Does it work offline?
Yes — generation is local. The only requirement is a secure context, which any https page is.
Can two generated UUIDs collide?
v4 collision needs about 2.7×1018 values for a one-in-a-billion chance. Practically, a bug that reseeds a generator is far more likely than a true collision.
Are UUIDs safe to expose in URLs?
Yes — they carry no information beyond randomness. That is precisely why they are preferred over sequential IDs, which leak volume and let anyone enumerate records.