UUIDs, generated in your browser
Version 4 identifiers from your browser's own cryptographic random generator. One at a time or by the hundred, with the structure explained — including the part everyone gets wrong.
A version 4 UUID holds 122 random bits, which is more than enough to be unguessable — but everything built around UUIDs assumes they are identifiers. They end up in logs, URLs, error reports, analytics and third-party systems, because that is what identifiers are for. If a value needs to be unguessable, generate a token and treat it like a password.
What the first one is made of
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
Which bits are random and which are not
A version 4 UUID is 128 bits, of which six are fixed: four say "this is version 4" and two mark the variant. That leaves 122 random bits, not 128 — a distinction that turns up whenever someone assumes a UUID is a 128-bit secret.
You can see the fixed bits in the text. The thirteenth hex digit is always 4, and the seventeenth is always 8, 9, a or b. Every version 4 UUID ever generated has those, which is how you can tell one apart from a version 1.
Will two of these ever collide?
In principle, yes — 122 bits is finite. In practice the number is one of those figures that stops meaning anything: you would need to generate about 2.7 × 10¹⁸ of them before the chance of a single collision reached 50%. At a billion a second that is roughly 85 years, and you would need the storage to hold them.
The real risk is not the mathematics but the generator. A UUID from a weak random source can and does collide — there are well-documented cases of libraries seeding from the clock and producing duplicates across machines that started together. This page uses crypto.randomUUID where available, which is required to draw from a cryptographically secure source, and falls back to crypto.getRandomValues with the version and variant bits set by hand.
The other versions, and when they matter
Version 1 encodes a timestamp and the machine's MAC address. That makes them sortable and leaks both when and where they were made — which is occasionally useful and more often a privacy problem nobody noticed.
Versions 3 and 5 are deterministic: hash a name within a namespace and you get the same UUID every time. Useful for deriving a stable identifier from something you already have.
Versions 6 and 7, standardised in 2024, put a timestamp at the front so the values sort chronologically. Version 7 is worth knowing about: random UUIDs as database primary keys scatter inserts across an index, and a time-ordered identifier avoids that. This page generates version 4 only, because that is the one people mean.
Common mistakes
Using one as a session token or password reset link. The entropy is adequate; the handling is not. Anything treated as an identifier will be logged, and a secret in a log is not a secret. Use a token from a generator that is meant for secrets.
Assuming they are sequential. Version 4 UUIDs have no order at all. Sorting them is sorting random numbers, and using them as a clustered primary key scatters every insert across the index — which is what version 7 was standardised to fix.
Storing them as text. A UUID is 16 bytes; the hyphenated form is 36 characters. In a database with millions of rows, storing the string rather than the binary costs more than twice the space and slows every comparison.
Related
The secure random generator for values that need to be unguessable, and the encoding converter to move a UUID between hex and other forms.
Questions people actually ask
Are these random enough to use as a secret?
The entropy is fine — 122 random bits is unguessable. The problem is everything around UUIDs: they are identifiers, so they get logged, put in URLs, sent to analytics and passed to third parties. A secret that appears in a log is not a secret. Generate a token instead and handle it like a password.
Why 122 bits and not 128?
Because six of the 128 are fixed: four spell out the version and two mark the variant. You can see them — the thirteenth hex digit is always 4 and the seventeenth is always 8, 9, a or b. That is how you tell a version 4 UUID from a version 1.
Could two of these collide?
You would need around 2.7 × 10¹⁸ of them before the chance reached 50% — a billion a second for 85 years. The realistic risk is not the mathematics but a weak generator; there are documented cases of libraries seeding from the clock and producing duplicates across machines that booted together. This page uses crypto.randomUUID where available, which must draw from a cryptographically secure source.
Should I use version 7 instead?
For database primary keys, quite possibly. Version 7 puts a timestamp at the front so values sort chronologically, which avoids scattering inserts across an index — the standard complaint about random UUIDs as keys. This page generates version 4 because that is what people mean by "a UUID".
Why not store them as text?
A UUID is 16 bytes; the hyphenated form is 36 characters. Across millions of rows that is more than twice the space, and every comparison is slower. Most databases have a native type for them.
Is anything sent anywhere?
No. They are generated in your browser and stay there. The download button writes a local file with no upload step.