What this generator actually produces
Version 4 UUIDs, and only version 4. A UUID is 128 bits written as 32 hex digits in an 8-4-4-4-12 grouping. In v4, 122 of those bits are random. The other six are fixed markers: the first hex digit of the third group is always 4 (the version), and the first hex digit of the fourth group is always 8, 9, a or b (the variant). If you generate a batch and notice every value has a 4 in the same position, that is the specification working, not a bug.
The randomness comes from crypto.randomUUID() when the browser has it, which is every current browser on a secure origin, and from crypto.getRandomValues() with the version and variant bits set by hand otherwise. Both are cryptographically secure pseudorandom generators seeded by the operating system. The tool shows you which one it used in the results. Math.random() is not used and would not be acceptable here: it is a fast non-cryptographic PRNG whose internal state can be recovered from a handful of outputs, which would make every subsequent value predictable — fine for shuffling a carousel, disqualifying for anything that functions as an identifier an attacker should not be able to guess.
The collision argument, and where it stops applying
122 random bits is about 5.3 x 1036 possibilities. Accounting for the birthday paradox, you would need to generate on the order of 1018 UUIDs before reaching a 50% chance of any two colliding. At a billion per second that is roughly 85 years of continuous generation. This is why UUIDs can be minted independently on every client, device and worker without a central allocator, which is the actual reason to use them.
All of that arithmetic assumes the bits are genuinely unpredictable. Substitute a weak RNG and the effective keyspace collapses to the size of the generator's internal state and its seed — famously, systems seeded from the current time in seconds have a keyspace of a few million. The security of a v4 UUID is entirely the security of its entropy source, which is why the source is worth checking in any library you use.
A related point: unguessable is not the same as secret. A v4 UUID is a fine session identifier or password-reset token precisely because it cannot be guessed, but it is also a fine primary key that appears in URLs and logs. Do not use the same UUID for both roles. If a value grants access, treat it like a credential.
v4 as a database key
Random keys scatter inserts across a B-tree instead of appending to the end of it, so every insert dirties a different page. On MySQL InnoDB, where the primary key is the clustered index, this shows up as page splits and a much larger working set once the table outgrows the buffer pool. PostgreSQL feels it less because the heap is separate from the index, but the index itself still fragments.
The fixes, in increasing order of effort: store the UUID as 16 bytes rather than as a 36-character string, which most engines support natively with a uuid or BINARY(16) column; keep a monotonic surrogate as the clustered key and put the UUID in a unique secondary index; or switch to a time-ordered identifier. UUID v7, standardised in RFC 9562, puts a 48-bit millisecond timestamp in the high bits so values sort roughly by creation time while keeping 74 random bits below that. ULID does the same thing with a different text encoding. This tool does not generate either — it makes v4 and says so — but if the reason you are here is a primary key on a high-insert table, v7 is the thing to go and read about.
Formatting variants
GUID is Microsoft's name for the same 128-bit structure. The {…} wrapping and uppercase hex are conventions from the Windows registry and .NET's Guid.ToString("B"), offered here because pasting into those contexts is easier when the format already matches. RFC 9562 specifies lowercase output and case-insensitive input, so a receiver that rejects uppercase is non-conformant, but the safe habit is to normalise to lowercase on the way into storage so string comparisons behave.
Stripping the dashes gives 32 characters, which is convenient in filenames, URL path segments and anywhere a hyphen would be ambiguous. Nothing is lost — the dashes are pure display convention, the positions are fixed, and essentially every parser accepts both forms. Just be consistent within one system, because a1b2… and a1b2-… are different strings to a database unique index even though they are the same UUID.
Questions people ask
How do v1, v4 and v7 differ?
v1 combines a timestamp with the machine MAC address, which sorts well but leaks the generating host and the creation time. v4 is 122 random bits and leaks nothing, which is why it became the default. v7 puts a millisecond timestamp in the leading bits followed by randomness, giving you rough sort order and index locality while still being unguessable in the tail. For a public identifier where ordering does not matter, v4. For a primary key on a write-heavy table, look at v7.
Are the UUIDs I generate here recorded anywhere?
No. They are produced by your browser and rendered into the page. There is no request and no storage; reloading the page loses them. If you need to keep a batch, copy it out before you navigate away.
Can I use one as a password reset token?
A v4 UUID from a cryptographic RNG has 122 bits of entropy, which is more than enough to resist guessing. The failure modes with reset tokens are elsewhere: not expiring them, not invalidating them after use, storing them in plaintext so a database read exposes them, and leaking them through referrer headers or logs. The identifier is the easy part.
Why do all of them have a 4 in the same place?
That digit is the version field, and it is fixed at 4 for every v4 UUID by RFC 9562. The first digit of the fourth group is similarly constrained to 8, 9, a or b — that is the variant field. Six bits are spent on those two markers, leaving 122 for randomness.