UUID Generator

A UUID is 128 bits printed as 32 hexadecimal digits in a 8-4-4-4-12 grouping. Six of those bits are spent on a version nibble and a variant marker; the rest carry whatever the version in question puts there. Three versions are offered here, and the difference between them 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 is the default and should stay the default unless you have a specific reason.

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, which is the RFC's own answer for a system that has no MAC address to offer. Version 7 is a later standard, defined in RFC 9562, and is 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. That distinction matters: Math.random, which many generators reach for, 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 changes this. Both embed the moment of creation in plain sight. Anyone holding one can read the timestamp back out, and given two of them can tell you how far apart they were issued. Use them as identifiers and sort keys; never use them as anything that needs to be unguessable.

Collision odds, stated plainly

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. Reaching 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 would wait around 85 years. The practical risk in any real system is not the mathematics; it is a broken random source, which is why the paragraph above is the important one.

Output shapes

Between 1 and 100 identifiers per run. Uppercase is a checkbox; 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 rather than a random one, a truncated digest from Hash Generator is the better instrument — 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 is no network call in this code path.