UUID generator

Where the randomness comes from

From your browser, through crypto.getRandomValues, the same source a password manager draws on. Nothing is requested from a server, so no value on this page has ever existed anywhere else, which is not something a generator that produces UUIDs server-side can say.

If that source is unavailable, the tool produces nothing and says why. It never falls back to Math.random, whose internal state can be recovered from a handful of outputs. That matters because a predictable UUID is indistinguishable from a good one by looking at it: if UUIDs are guarding unlisted URLs or acting as idempotency keys, a weak source is a vulnerability nobody will notice.

Version 4 against version 7

Version 4 is 122 random bits and six fixed ones marking the version and variant. It carries no information at all beyond being unique, which is usually exactly what is wanted.

Version 7, standardised in RFC 9562, puts a 48-bit millisecond timestamp at the front and fills the remainder with randomness. Two consequences follow. They sort chronologically as plain strings, which makes them far kinder to a database index, random keys scatter through a B-tree and fragment it, while ordered keys append. And they disclose roughly when they were created, which is occasionally more than you want to give away.

The ordering is to the millisecond and no finer. A batch generated in one go shares a timestamp, so those values are in no particular order among themselves. You will see that above if you generate several at once. RFC 9562 offers an optional counter for keeping same-millisecond values ordered; it is not implemented here, because it only helps a single generator and gives nothing across several machines.

What is not here, and why

Version 1 embeds the MAC address of the machine that generated it. A browser cannot read one, so generating a version 1 UUID here would mean fabricating that field, producing a value that claims to identify a machine and does not. Version 6 has the same problem.

Versions 3 and 5 are not generated at all; they are hashes of a name inside a namespace, so they are derived from inputs you would have to supply. A button that produced one without asking would be producing a hash of nothing.

Unguessable is not the same as secret

A version 4 UUID is safe to use where guessing it must be infeasible: an unlisted share link, an idempotency key, a correlation ID. It is not an authentication token. Anyone who comes by one, from a log file, a referrer header, a screenshot, keeps it, and unlike a session token it cannot meaningfully be rotated. Treat it as a name that is hard to guess rather than as a credential.