UUID Generator

How to use the UUID generator

Set the count, pick a format, and the identifiers appear straight away. Pressing "Generate new" replaces the whole batch, and changing the format rewrites what is already on screen rather than drawing fresh values, so an identifier you have already pasted somewhere does not quietly change underneath you.

Everything happens in the page in front of you. The values come from your browser cryptographic random generator, nothing is sent to a server, nothing is logged, and no identifier is ever written into the URL. Close the tab and the batch is gone.

The four formats carry exactly the same bits. Hexadecimal is case insensitive, so uppercase changes nothing about the value, and the hyphens are punctuation rather than data. Choose whichever the receiving system prints, because matching its output makes a mismatch obvious at a glance.

Version 4 is random and version 7 is time ordered. Both are defined in RFC 9562, and both use the same 128-bit layout. A v7 identifier puts a millisecond timestamp in its high bits, so a list of them sorts into creation order without a separate column.

That difference matters most in a database. Random keys land in random pages of a B-tree index, so a busy table keeps rewriting pages all over the disk. Time-ordered keys append near the end, which is cheaper to write and friendlier to the cache.

Should a database key be version 4 or version 7?

Version 7 in almost every case where the identifier is also the primary key. RFC 9562 added it in May 2024 precisely because random keys behave badly in an index, and the fix is to move the entropy out of the high bits and put a timestamp there instead.

A version 7 value begins with 48 bits of Unix milliseconds, then the version nibble, then 74 random bits. Two rows created in the same millisecond still differ, and rows created in order sort in order, which is what a B-tree wants.

• Primary key on a table that grows: version 7.
• Identifier shown to a user or sent to a third party: version 4 leaks nothing about timing.
• Correlation id in a log or trace: version 4 is fine and simpler.
• Anything that must be unguessable: neither, use a secret generator.

Version 4 is still the right answer whenever the creation time is itself sensitive. A v7 identifier tells anyone who receives it roughly when the record was made, down to the millisecond, and that is information you may not want to hand out with an order number.

Why a UUID is not a security token

Unguessable and unlikely to repeat are different properties. A version 4 UUID from a cryptographic source has 122 bits of entropy, which sounds like plenty, and in isolation it is. The problem is everything else the format encourages.

Identifiers get printed in URLs, server logs, analytics payloads, error reports and support tickets. A secret that has been through all of those is no longer a secret, and no amount of entropy fixes a value that was designed to be shared.

There is a second trap. Not every UUID-shaped string came from a cryptographic source: plenty of older libraries built them from the clock, the process id and a weak pseudo-random function. A value that looks like a v4 UUID tells you nothing about how it was made.

The formula, worked line by line

A UUID is 128 bits, written as 32 hexadecimal digits in five hyphenated groups. In version 4 all of those bits start out random and then six of them are overwritten: four for the version and two for the variant. What survives is 122 bits of genuine unpredictability.

Collision odds are not one divided by the number of values. They follow the birthday problem, because a repeat can happen between any pair in the batch and the number of pairs grows with the square of the batch size. That is why the answer arrives far sooner than intuition suggests.

total bits = 128
version nibble = 4 bits, forced to 0100
variant bits = 2 bits, forced to 10
random bits = 128 - 4 - 2 = 122
distinct values N = 2^122 = 5,316,911,983,139,663,491,615,228,241,121,378,304
P(at least one repeat in n draws) = 1 - e^(-n^2 / 2N)
n for a given probability p = sqrt(2N x ln(1 / (1 - p)))

Two of the digits give the format away. Take the canonical form, count to the first digit of the third group, and a version 4 identifier always shows a 4 there. The first digit of the fourth group is always 8, 9, a or b, because its top two bits were forced to 10.

This tool sets those bits by hand only when it has to. Where the browser provides its own UUID function it is used directly, because a runtime implementation is better tested than anything a web page can write. The fallback takes 16 random bytes and rewrites the same two positions.

The entropy figure only describes the process. If a library seeds a fast pseudo-random function with the current time, the output still has the shape of a v4 UUID and still passes a format check, while the real number of possible values may be a few million rather than 5.3 x 10^36.

Questions people ask