UUID Generator

Details

About this tool

Generates version 4 UUIDs in bulk from the browser's own cryptographic random source. Choose how many, whether to keep the hyphens and whether to upper-case them.

A UUID is a 128-bit identifier written as 32 hexadecimal characters in five hyphenated groups. Version 4 means it is essentially all random: 122 of those bits come from the random source, and the remaining six mark the version and variant, which is why the thirteenth character is always 4 and the seventeenth is always 8, 9, a or b. Those two fixed positions are a quick way to tell what kind of UUID you are looking at.

The point of a UUID is that it can be created anywhere, by anyone, without asking a central authority whether the value is taken - which is what an auto-incrementing database column cannot do. That makes it the natural key for records created offline, merged from several systems, or generated by a client before the server has ever heard of them. It also means the identifier gives nothing away about how many records exist, unlike a sequential id that tells any visitor how many customers you have.

Collisions are not something to plan around. With 122 random bits you would need to generate billions of UUIDs per second for a century before a duplicate became likely. What matters far more is the quality of the randomness, which is why these come from crypto.getRandomValues rather than Math.random - the latter is predictable and has no business generating identifiers. Nothing is requested from a server, so the values are yours alone.

Good to know

Questions people actually ask

Are these UUIDs really random?

Yes. They come from crypto.getRandomValues, the browser's cryptographic random source, not from Math.random. That distinction matters: Math.random is fast, predictable and fine for shuffling a list, but an attacker who sees a few of its outputs can work out the rest, which would be a real problem for a token or a session id.

What makes it a version 4 UUID?

The version and variant bits. In a v4 UUID the thirteenth hexadecimal character is always 4 and the seventeenth is always 8, 9, a or b; the other 122 bits are random. Version 1 UUIDs are built from a timestamp and a MAC address instead, and version 7 - the newer, time-ordered one - sorts chronologically, which databases like.

Could two UUIDs ever be the same?

In principle yes, in practice never. With 122 random bits you would need to generate billions per second for about a century before a duplicate became likely. The realistic risk is not the mathematics but a weak random source, which is exactly what using the cryptographic one avoids.

Should I use a UUID as a database primary key?

It depends on the database. UUIDs are ideal when rows are created in several places at once or offline, because no coordination is needed. The cost is that random values scatter writes across a B-tree index, which hurts insert performance and index size on a large table - PostgreSQL and MySQL both feel it. If that matters, UUIDv7 keeps the independence while sorting by time.