Generate v4 and v7 UUIDs in bulk, with an inspector. Crypto-grade, in your browser.
This UUID generator creates identifiers in bulk, in both version 4 and version 7. Version 4 is fully random, the safe default when an ID should reveal nothing; version 7 stamps the time into the front so the IDs sort by creation order, which is what you want for modern database keys. Generate one or fifty at a click, copy any of them or all at once, and an inspector reads any UUID you paste back to its version, its variant, and for v7 the exact moment it was made. Everything uses the browser's cryptographic generator, not the weak Math.random, and nothing is sent anywhere, so they're safe to use as real identifiers.
100% in your browser. Nothing you type ever leaves this page.
- Version
- ...
- Variant
- ...
- Created (v7 only)
- ...
Two versions, two jobs
A UUID is a 128-bit identifier you can generate anywhere without asking a central authority, and it won’t collide with anyone else's. Version 4 is pure randomness, which is what you want when the ID should reveal nothing and have no order. Version 7 trades a little of that: it stamps the current time into the front, so the IDs sort chronologically. Both are generated here with the browser's cryptographic generator, not the weak Math.random.
Why v7 is winning for database keys
If you use UUIDs as primary keys, random v4 values land all over the index, so every insert pokes a different page and write performance suffers as the table grows. Time-ordered v7 keys append near each other, which keeps the index tight and inserts fast, while still being globally unique. The tradeoff is that a v7 quietly encodes its creation time, which the inspector above will read straight back out.
Generated locally, safe to use
Everything happens in your browser, nothing is sent or logged, so these are real identifiers you can drop into code or a database. Need to turn a date into a number while you’re here? The epoch converter is next door.
The question nobody asks until the table is large: how do you store one? A UUID written out is 36 characters, and a CHAR(36) column costs you 36 bytes per row plus the same again in every index that touches it. Stored as BINARY(16) it’s sixteen. On ten million rows that’s a couple of hundred megabytes of index you don’t have to keep in memory, and the only cost is converting on the way in and out. Postgres has a native uuid type that already does this for you. MySQL doesn’t, so people default to the string form and pay for it quietly for years.
Frequently asked questions
v4 or v7, which should I use?
v4 is fully random, the safe default for an identifier that should leak nothing and sort nowhere. v7 puts a millisecond timestamp in the front, so v7 IDs sort by creation time. If you use UUIDs as database primary keys, v7 is usually the better pick: random v4 keys scatter writes across the index and hurt insert performance, while time-ordered v7 keys append cleanly.
Are these random enough to be unique?
Yes. Both versions use the browser crypto generator (the same CSPRNG used for keys), not Math.random. v4 has 122 random bits, so a collision is astronomically unlikely even across billions of IDs. v7 keeps 74 random bits per millisecond, which is plenty to avoid collisions within the same tick.
Can I read the timestamp back out of a v7?
Yes, and the inspector does it: the first 48 bits are the Unix time in milliseconds. Paste any UUID and it reports the version and variant, plus the embedded creation time for v7. That’s a feature for sorting and debugging, but remember it also means a v7 leaks roughly when it was made.
Is anything sent to a server?
No. Generation and inspection happen entirely in your browser with the built-in crypto API. Nothing is logged or transmitted, so these are safe to use as real identifiers.