uuid generator
Version 4, from the browser's own cryptographic randomness.
Version 4, from crypto.randomUUID: 122 random bits each, so a collision is not something to plan around.
The short answer
A version 4 UUID is 122 random bits with six bits spent saying which version it is. The randomness comes from the browser's cryptographic generator, so two of them colliding is not a thing to design around: you would need to generate billions before it became plausible.
One identifier or two hundred, generated by crypto.randomUUID in this tab. No sequence, no server, and nothing recorded about what you generated.
The formula
8-4-4-4-12 hex digits, of which 122 bits are random
Worked examples
- The 13th character
- always 4, the version
- The 17th character
- always 8, 9, a or b
- The other 30
- random hex
Reference table
| Version | Made from | Sorts by time | Use it when |
|---|---|---|---|
| 4 | Random bits | No | You want an id and nothing else |
| 1 | Time and MAC address | Roughly | Legacy systems expect it |
| 7 | Time, then random | Yes | The id is a database key |
| Nil | All zeroes | No | You need a placeholder |
How to use it
- 01Choose how manyOne to two hundred. They arrive one per line, ready to paste.
- 02Copy the listGenerated in the page; nothing is sent anywhere or logged.
Also searched for
Searches that land here include uuid generator, guid generator, random uuid, uuid v4 and generate guid online.
What a UUID is, and is not
128 bits, six of them bookkeeping
The familiar 8-4-4-4-12 shape holds 32 hexadecimal digits, which is 128 bits. Six of those say which version and variant it is, leaving 122 that are random. That is why the thirteenth character of a version 4 UUID is always a 4, and the seventeenth is always 8, 9, a or b: they are the labels, not the payload.
Why they exist
To let two systems that have never spoken to each other mint identifiers without coordinating. A database sequence needs one authority to hand out the next number; a UUID needs nobody, which is what makes it useful for offline clients, distributed systems and anything generating records before it can reach a server.
The database cost
Random identifiers scatter. Insert a million version 4 UUIDs as a primary key and every write lands in a different part of the index, which fragments it and slows the whole table down. Version 7 exists precisely to fix that, by making the first bits a timestamp so new rows land next to each other.
Questions people ask
Could two of these ever be the same?
In principle, and never in practice. A version 4 UUID has 122 random bits, so you would need to generate somewhere around a billion a second for decades before a collision became likely. It is one of the few cases where ignoring the risk entirely is the correct engineering decision.
Should I use version 4 or version 7?
Version 4 if the identifier is just an identifier. Version 7 if it is a primary key: it puts a timestamp at the front, so ids sort by creation time and a database index stays compact instead of scattering writes across the whole tree. Random keys are the classic cause of index bloat.
Is a UUID a secret?
A version 4 one is unguessable, which is not quite the same thing. It is fine as an unguessable URL for a share link. It is not fine as an authentication token, because it will end up in logs, referrer headers and browser history where a password never would.