UUID Generator

Version 4 or version 7?

A version 4 UUID is 122 random bits in a fixed format. It reveals nothing — not when it was made, not where — which makes it the right default wherever an identifier will be seen by others and should not leak anything about its origin.

Version 7, introduced in RFC 9562 in 2024, puts a 48-bit Unix timestamp in milliseconds at the front, and the remaining 80 bits hold the version, the variant and 74 bits of randomness. Because the timestamp leads, v7 UUIDs sort in the order they were created, both as text and as bytes.

That ordering is why v7 has become the usual recommendation for database primary keys. A B-tree index stays compact when new keys arrive at its end; random v4 keys land all over it, splitting pages and pushing the working set out of memory as a table grows. Time-ordered keys keep inserts at the right-hand edge, much like an auto-incrementing integer, without a central counter to hand them out.

The trade-off is that a v7 UUID announces its creation time, to the millisecond, to anyone who sees it — paste one into the inspector and look. For an order number or user ID that appears in a URL that may be more than you want to disclose, and v4 is the better choice there.

How the 128 bits are laid out

A UUID is 16 bytes written as 32 hexadecimal digits in five groups: 8-4-4-4-12. Two positions are fixed by the standard. The first digit of the third group is the version — the 4 in xxxxxxxx-xxxx-4xxx-… — and the first digit of the fourth group carries the variant, which for every UUID made to the RFC is 8, 9, a or b, because its top two bits are 10.

In version 7 the first twelve hex digits are the timestamp. The example in RFC 9562, 017f22e2-79b0-7cc3-98c4-dc0c0c07398f, begins 017f22e279b0, which is 1,645,557,742,000 milliseconds after 1 January 1970: 22 February 2022 at 19:22:22 UTC. This generator also uses the 12 bits after the version as a counter, seeded at random each millisecond, so a thousand UUIDs made within the same millisecond still come out in strictly increasing order. That is the monotonic method the RFC describes, and it means a sorted list of them matches the order they were generated.

Version 1, the original time-based design, counts 100-nanosecond intervals since 15 October 1582, the first day of the Gregorian calendar, and splits that count across the first three groups in an awkward order. That is why v1 UUIDs do not sort by time, and why version 6 was defined as the same thing rearranged. Version 1 ends with a node ID that was traditionally the generating machine's network MAC address; the inspector decodes the timestamp and says whether the node looks like a real one.

Two special values complete the set: the nil UUID, all zeros, and the max UUID, ffffffff-ffff-ffff-ffff-ffffffffffff, which RFC 9562 added as a sentinel. Neither has a version.

How unique is unique?

With 122 random bits, you would need to generate about 2.7 × 10¹⁸ version 4 UUIDs — 2.7 quintillion — before the chance of a single duplicate reached one in two. At a billion a second that takes roughly 86 years. Version 7 has fewer random bits, but a v7 UUID can only collide with one made in the same millisecond, and the counter keeps apart those made by the same generator.

Real collisions come from broken randomness, not arithmetic: generators seeded from the clock, virtual machines cloned with identical random state, code that builds UUIDs from Math.random. This tool takes its randomness from the browser's cryptographic generator — crypto.randomUUID where the browser offers it, crypto.getRandomValues otherwise — the same source used for encryption keys.

Unique is not the same as secret. RFC 9562 says plainly that UUIDs should not be assumed hard to guess and must not be used as security capabilities, where merely knowing an ID grants access. For session tokens, password-reset links and API keys, use a generator designed for secrets, such as the password generator on this site.

Formats you will run into

The standards write UUIDs in lowercase with hyphens and treat case as insignificant on input. Microsoft tools traditionally show GUIDs in uppercase inside braces — {6F9619FF-8B86-D011-B42D-00C04FC964FF} — which is the same kind of value in different clothes. The URN form, urn:uuid: followed by the UUID, is for places that require a URI. Some databases and URLs drop the hyphens and use the 32 digits bare, and PostgreSQL's uuid type, like most libraries, accepts that on input.

Byte order is the trap. Microsoft's GUID structure stores its first three groups little-endian, so the same GUID turned into bytes by .NET and by most other languages gives different byte sequences — and a UUID read back from raw bytes in the wrong order shows a version digit that makes no sense. If the inspector reports an undefined version for an ID that came out of a binary column, endianness is the likely culprit.