uuid v4 generator online
A UUID v4 carries 122 bits of pure chance: of the 128 total bits, 4 are fixed to "0100" to mark the version and 2 mark the RFC 4122 variant, leaving 122 for the generator to roll. This tool's quality is not in the format, which any library reproduces, it is in where those 122 bits come from.
The 13th hex digit is "4" (version) and the fourth group's first hex digit is "8" (RFC 4122 variant, its first two bits read "10").
The mask erases the original high nibble and writes "4" in its place, always, whatever the drawn byte was.
The second one generated can sort lexicographically before the first; only version 7, with its embedded timestamp, guarantees creation order.
A UUID v4 is a 128-bit unique identifier generated with random bits, except for the 4 version bits and 2 variant bits, which leaves 122 truly random bits. The format is xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, where the version digit is always 4 and y is 8, 9, a or b.
Because Math.random() runs a fast, non-cryptographic pseudorandom generator; the language spec itself (ECMA-262) says the function need not produce a sequence secure against prediction. crypto.randomUUID() reads from the OS CSPRNG, the same source used to generate session keys and tokens, and it is the path this tool uses by default.
Technically yes, but with a performance cost: the 122 random bits scatter every insert into an unpredictable index position, forcing reorganizations a sequential key would avoid. For that specific case, version 7 from the same RFC 9562 solves the problem, because it embeds the creation timestamp in its first 48 bits and comes out naturally sortable.
Generating 1 billion UUID v4s at once leaves the odds of any pair matching around 9.4×10⁻²⁰, a direct calculation from the birthday-paradox approximation over 2^122 possible values. At that scale, the practical risk for a real system does not come from the UUID math, it comes from an implementation bug, like reusing the same value by mistake.