UUID Generator

Everything is read and written on the sixteen octets rather than on the hyphenated string. That sounds like an implementation detail and is not: reading a version by taking character 14 and a variant by taking character 19 works only for one exact spelling, and the string positions are one off from the octet boundaries in a way that is easy to get wrong. Working on the octets is also what lets the tool accept a UUID in braces, with a urn:uuid: prefix, in upper case, or with the hyphens missing, and still say what it is.

RFC 9562 defines seven versions and this tool generates six of them, leaving out v2, which is a DCE security variant almost nobody uses. Which one you want depends on one question: does the order matter? A v4 is 122 random bits and sorts arbitrarily, which is fine for a value nothing indexes. A v7 puts the Unix millisecond in the first 48 bits, so a batch sorts by time as plain strings, which keeps database inserts at the end of an index instead of scattered through it. A v6 does the same job by reordering v1’s time fields; a plain v1 does not sort, because its string starts with the low 32 bits of the clock, which wrap every 429.5 seconds, and the tool says so next to each format rather than lumping them together as "time based".

The time-ordered versions are monotonic within a millisecond, which is the part that is usually missing. A generator that redraws its random field every call produces values that are unique but land in an arbitrary order when several are made in the same millisecond, and that is exactly the case a time-ordered identifier exists to handle. Here v7 carries a counter in its rand_a field, the way RFC 9562 section 6.2 method 1 describes; v1 and v6 keep a stable clock sequence and node; ULID increments its previous random field, which its own specification calls the monotonic factory; and Snowflake moves its timestamp on when the 12-bit sequence fills, rather than reusing a sequence number. Four thousand v7 made in one millisecond come out unique and in order, and the panel says on screen whether the batch you are looking at sorts in the order it was made.

v3 and v5 are the deterministic ones: MD5 or SHA-1 over a namespace UUID followed by a name, so the same input always gives the same UUID and nothing has to be stored to look it up again. Pick one of the four namespaces RFC 9562 defines (DNS, URL, OID, X.500) and type a name. These are checked against digests computed independently: v5 of "www.example.com" in the DNS namespace is 2ed6657d-e927-568b-95e1-2665a8aea6a2 and v3 of the same is 5df41881-3aed-3515-88a7-2f4a814cf09e, and the tool produces both.

There is a chi-square test built in, which draws twenty thousand identifiers and checks that every character occurs equally often, reporting the statistic against the published 0.01 critical value. It is honest about what that proves: a chi-square cannot tell a cryptographic generator from `Math.random`, which passes it comfortably and is still guessable from a handful of outputs. The source is therefore stated separately, because it is the part that actually matters.

A v1 also carries a node identifier. When that node is not a real network address, RFC 9562 section 5.1 requires the multicast bit of its first octet to be set, so a generated node can never collide with a hardware one; the generator here sets it and keeps the same node for the life of the page, because a v1 is meant to be ordered by time and node and one that changes every call is not.