At a glance
| Output | Version 4 UUIDs, from the browser crypto source |
|---|---|
| How many | 1 to 1000 at a time, default 5 |
| Where it runs | Entirely in your browser — no file is uploaded to a server |
| Price | Free, with no account and no sign-up |
| Offline | Works with no connection after the first visit |
What version 4 means
A v4 UUID is 122 random bits with six fixed to mark the version and variant. There is no timestamp, no MAC address and no counter — nothing that leaks when or where it was made, which is exactly why v1 fell out of favour.
The randomness here comes from crypto.getRandomValues(), the same source a key would use. A generator built on Math.random() produces values that look identical and are predictable in sequence.
Will two ever collide?
In practice, no. With 122 random bits you would need to generate about 2.7 x 10^18 of them before reaching a one-in-a-billion chance of any pair matching. At a million a second that is longer than the universe has existed.
The real collision risk is not the maths. It is a generator seeded badly — a fresh virtual machine with no entropy pool, or a library falling back to Math.random().
Before you make it a primary key
Random UUIDs scatter across a B-tree index, so inserts touch pages all over the disk and the index fragments. On a large table that is a measurable write cost, and it is why databases with heavy insert loads often prefer a sequential ID with a UUID alongside it for external use.
UUIDv7, which puts a timestamp in the high bits, exists precisely to keep the ordering while staying globally unique.
Frequently asked questions
Could two UUIDs ever be the same?
Not in any realistic scenario — 122 random bits is an unimaginably large space. The practical risk is a badly seeded generator, not the odds.
Are these safe to use as security tokens?
They come from a cryptographic source, so the randomness is sound. But a UUID is usually visible in URLs and logs; use a purpose-made token for anything that grants access.
Should I use a UUID as a database primary key?
It works, but random values fragment the index and slow inserts on large tables. A sequential internal key with a UUID for external references is a common compromise, as is UUIDv7.
What is the difference from v1?
Version 1 encodes a timestamp and the machine’s MAC address, which leaks when and where it was generated. Version 4 is random throughout.
Something wrong with this tool, or an idea for it? Tell us