UUID Generator
Generate UUIDs using the browser's crypto.getRandomValues (cryptographically random,
not Math.random). v4 for fully random IDs; v7 for time-ordered IDs that work well as
database primary keys. Bulk mode up to 1,000 at a time.
UUID versions explained
| Version | Use case | Trade-off |
|---|---|---|
| v1 | Time + MAC address | Leaks machine and time; not recommended |
| v4 | Random | No information leak; bad for clustered DB indexes |
| v7 | Time + random (RFC 9562) | Sortable; works as DB primary key; no MAC leak |
| nil | All zeros placeholder | Reserved sentinel value |
| max | All ones placeholder | Reserved sentinel value, RFC 9562 |
Why v7 matters for databases
InnoDB, PostgreSQL B-tree, and most other database indexes store rows in key order. Random v4 UUIDs scatter inserts across the entire index, causing page splits and write amplification. v7 UUIDs sort by time, so new inserts go to the same hot pages — same locality benefit as auto-increment integers, without the centralization downside.
Frequently asked questions
When should I use v4 vs v7?
v7 (timestamp-ordered, RFC 9562) when UUIDs become database keys — the time prefix means new rows append to the end of a clustered index instead of fragmenting it. v4 (fully random) when the UUID will live somewhere indexes don't care about ordering, or when revealing creation time is undesirable.
Are UUIDs guaranteed unique?
v4 UUIDs have 122 random bits — collision probability is ~1 in 10^36 for ten billion UUIDs. Treat them as unique. v7 adds a millisecond timestamp; collisions within the same millisecond rely on 74 random bits, still well past practical concerns.
Why doesn't this tool generate v1?
v1 leaks the generating machine's MAC address and the precise time of generation. v7 is the modern replacement for "time-ordered UUID" use cases without those leaks. v1 is supported by request — open an issue.