Encode Bench › UUID Generator
UUID Generator
Choose a version and a count. Version 4 is fully random; version 7 embeds a timestamp so identifiers sort chronologically, which matters a great deal for database index performance.
● Runs locally. What you paste never leaves this page.
Version 4 and version 7
A UUID is 128 bits written as 32 hexadecimal digits in five hyphenated groups. Several versions exist, distinguished by how those bits are chosen. Two matter in practice today.
Version 4 is 122 random bits, with six bits fixed to identify the version and variant. It is the default nearly everywhere, and it is what people usually mean by "a UUID".
Version 7, standardised in RFC 9562 in 2024, replaces the first 48 bits with a Unix millisecond timestamp and fills the rest with randomness. The result is still globally unique but sorts chronologically as text, which turns out to matter enormously.
Why version 7 is usually the better default for a database key
Database indexes are B-trees, and B-trees are much happier when new keys arrive in ascending order. A v4 primary key lands at a random position in the index on every insert, which spreads writes across the whole structure, causes page splits, and steadily degrades cache locality as the table grows. On a large table this is a measurable and often severe write penalty.
A v7 key always lands at the end. Inserts append, the hot region of the index stays small enough to remain cached, and page splits become rare. Range queries over a time window also become possible directly on the primary key. If you are choosing an identifier for a new table today, v7 is very often the right pick.
The tradeoff is that v7 discloses roughly when the record was created. For a public-facing identifier where creation time is sensitive, or where sequential identifiers would let someone estimate your volume, v4 remains the safer choice.
Collisions
With 122 random bits, the probability of a collision is negligible for any realistic volume. To reach a one in a billion chance of a single collision you would need to generate on the order of a hundred billion UUIDs. This is why UUIDs can be generated independently on many machines without coordination, which is their entire point.
That guarantee depends on the randomness being cryptographically strong.
These are generated with crypto.getRandomValues, your browser's
CSPRNG. Implementations built on Math.random, which still circulate
widely, do not have that property and can repeat.
Formatting variants
The canonical form is lowercase with hyphens. Microsoft tooling conventionally wraps a GUID in braces, and some databases store the value without hyphens as a 32-character string or as 16 raw bytes. The options above cover these, but store one form consistently: comparing a hyphenated value to an unhyphenated one is a bug that surfaces long after it is introduced.
Questions
Should I use v4 or v7?
Use v7 for database keys, because the embedded timestamp keeps index inserts sequential and avoids the write amplification that random keys cause. Use v4 when the identifier is public and the creation time should not be inferable.
Are these random enough to be safe?
Yes. They use crypto.getRandomValues, your browser's cryptographically secure generator. Avoid any implementation built on Math.random, which is not suitable and can produce repeats.
How likely is a collision?
Negligible. Version 4 carries 122 random bits, so reaching even a one in a billion chance of a single collision requires on the order of a hundred billion identifiers.
Does a v7 UUID leak information?
It embeds the creation time to millisecond precision, so anyone holding one can tell when the record was made. That is usually harmless internally but worth avoiding for public identifiers where timing is sensitive.
Are the generated values sent anywhere?
No. Generation happens entirely in your browser and nothing is transmitted or logged, so the values are yours alone.