UUID Generator

A UUID is 128 bits printed as 32 hexadecimal digits in an 8-4-4-4-12 grouping. Six of those bits go on a version nibble and a variant marker, and the rest carry whatever that particular version puts there. Three versions are offered here, and how they differ matters more than the format they share.

Which version to pick

Version 4 is 122 random bits. It carries no information about when or where it was made, which is exactly what you want for anything a user might see or send back to you. It's the default, and unless you have a specific reason to change it, leave it that way.

Version 7 puts a 48-bit Unix millisecond timestamp in the leading bytes and fills the remainder from the random source. Sorting a list of v7 values lexicographically sorts them by creation time, which is why they behave so much better than v4 as a primary key. Rows land at the end of a B-tree index instead of scattering across it, and page splits drop away.

Version 1 is the original layout from RFC 4122: a 60-bit count of 100-nanosecond intervals since 15 October 1582, a 14-bit clock sequence, and a 48-bit node identifier. This implementation keeps a counter for ids generated inside the same millisecond, advances the clock sequence when that counter wraps or the system clock steps backwards, and uses a random node with the multicast bit set. That last part is the RFC's own answer for a system with no MAC address to offer. Version 7 is a later standard, defined in RFC 9562, and it's the better choice for new work.

Where the randomness comes from

Version 4 uses crypto.randomUUID where the browser provides it, and crypto.getRandomValues otherwise. Both are the platform's cryptographically secure generator, seeded by the operating system. Many generators reach for Math.random instead, which is a fast non-cryptographic PRNG whose internal state can be recovered from a handful of outputs, so anything derived from it is guessable by someone who has seen enough of it. Version 4 here is suitable for a session token or a password-reset link.

Versions 1 and 7 are a different matter, and no fix can change that, because both embed the moment of creation in plain sight. Anyone holding one can read the timestamp back out, and with two of them can tell you how far apart they were issued. Use them as identifiers and sort keys, but never for anything that needs to be unguessable.

Collision odds

For version 4 the useful approximation is:

P(at least one collision) ~= n^2 / (2 * 2^122)

With n = 1 trillion identifiers, that works out to roughly one chance in ten trillion. Getting to an even-money bet on a single duplicate takes about 2.7 x 10^18 values. Generate a billion of them every second and you'd wait around 85 years. In any real system the practical risk is a broken random source, not the mathematics, which is why the previous section is the one to take seriously.

Output shapes

You can generate between 1 and 100 identifiers per run. Uppercase is a checkbox. The prefix and suffix fields wrap each value, so { and } gives you the Microsoft GUID form and a trailing comma gives you something you can paste straight into an array. The format selector emits a raw list, a JSON array, one CSV line, or a batch of INSERT statements ready for SQL Formatter.

If what you actually need is a short deterministic key derived from content, a truncated digest from Hash Generator is the better tool. The same input will always give you the same key, which no UUID version can do.

Generation happens entirely in your browser. No identifier is requested from or reported to a server, and there's no network call in this code path.