UUID Generator
Generate cryptographically random v4 UUIDs in bulk.
v4 is 122 bits of randomness from crypto.getRandomValues(). Collisions are not a practical concern.
About this tool
Generate up to a thousand identifiers at once using the browser's cryptographic random source. Version 4 is purely random; version 7 embeds a timestamp so identifiers sort chronologically, which indexes far better as a database primary key.
How to use it
- Choose v4 (random) or v7 (time-ordered).
- Set how many you need and pick a formatting option.
- Copy the list, or download it as a text file.
Why v4 UUIDs hurt database performance
A version 4 UUID is 122 random bits. Excellent for uniqueness, poor as a primary key on a large table.
Database indexes are B-trees: sorted structures stored in fixed-size pages. Sequential keys always append to the same end page, which stays hot in memory. Random keys land in arbitrary pages, which means:
- Random I/O instead of sequential writes
- Page splits — inserting into a full page splits it in two, leaving both half-empty
- Index bloat from all those half-empty pages
- A useless cache, because writes are spread across the whole index
At a few thousand rows this is invisible. At tens of millions it is not.
What v7 changes, and when to still use v4
Version 7 puts a 48-bit big-endian Unix millisecond timestamp in the first six bytes, then fills the rest with randomness. Because the timestamp leads and is big-endian, sorting the identifiers sorts them by creation time — so inserts append, exactly like an auto-increment integer, while keeping the properties that made UUIDs attractive: generate anywhere, no coordination, no sequence leaking your row count.
Use v7 for primary keys and anything written in volume.
Use v4 when the identifier is public and its creation time should not be. A v7 value tells anyone holding it the millisecond it was generated — usually harmless, occasionally a real leak. Password reset tokens, share links and public object ids are better as v4.
Both versions here come from crypto.getRandomValues(), the same cryptographically secure source used for key generation — not Math.random().
Frequently asked questions
- When should I use v7 instead of v4?
- Use v7 for database primary keys. Because the first bytes encode a timestamp, new rows append to the end of the index instead of scattering across it, which avoids the page-split churn random v4 keys cause.
- Are these actually random?
- Yes. They come from crypto.getRandomValues(), the same cryptographically secure source used for key generation — not Math.random().
- Are the identifiers generated on a server?
- No. They come from crypto.getRandomValues() in your own browser, so nobody else has ever seen them and no two visitors can receive the same batch.