UUID Generator

A UUID is a 128-bit identifier you can generate anywhere, without asking a central authority whether it is already taken. That property is the entire point: two services on opposite sides of a network can each mint identifiers and rely on never colliding.

This generator produces version 4 UUIDs — the random kind — and version 7, the time-ordered kind you want for database keys, in bulk and from your browser's cryptographic random source. The nil and max UUIDs are here too, since both are constants people copy rather than generate.

The inspector goes the other way. Paste any UUID and it reports the version, the variant, and, for the versions that carry one, the timestamp buried in the bits — which is how you find out whether the id in your logs was created last Tuesday or is not a real UUID at all.

A version 7 UUID starts with a 48-bit Unix millisecond timestamp, big-endian, followed by a counter and random bits. Because the timestamp is at the front and most significant first, sorting the strings sorts them by creation time — which a version 4 UUID, being random from end to end, can never do.

That matters for database primary keys. Random UUIDs land all over a B-tree index, so every insert dirties a different page and a busy table ends up rewriting far more of its index than it needs to. Time-ordered values append near the end instead, which is the behaviour an auto-increment key gives you, without giving up the ability to generate ids on the client.

The generator here also keeps a counter in the twelve bits after the version nibble, seeded randomly on each new millisecond. Without it, every id created inside the same millisecond would be ordered by its random bits — so a burst of fifty would come out shuffled, which defeats the point. With it, a batch is strictly increasing even when the clock does not move between values.

The cost of v7 is that it tells anyone holding one roughly when it was created, to the millisecond. That is usually harmless and occasionally not: an id in a public URL now leaks the record's creation time, and a sequence of them leaks how quickly you are creating records.

It is written in the value. The first character of the third group — the thirteenth hex digit — is the version, so a UUID reading …-4f3a-… is version 4 and …-7cc3-… is version 7. The first character of the fourth group encodes the variant, and for anything following the modern standard it is 8, 9, a or b.

The variant is the part people forget, and it is the more useful check. If those bits do not say RFC 9562, the version nibble is not a version at all — you may be looking at a legacy Microsoft GUID, or at sixteen bytes of something else formatted to look like a UUID. The inspector reports both, and withholds the timestamp when the variant says the version cannot be trusted.

Versions 1, 6 and 7 carry a clock. Version 1 and version 6 count 100-nanosecond ticks since 15 October 1582 — the date the Gregorian calendar was adopted — while version 7 uses plain Unix milliseconds. All three are decoded here; versions 3, 4, 5 and 8 have no timestamp to find.

In principle yes, in practice no. Version 4 leaves 122 bits random, so you would need to generate on the order of a billion a second for a century before a collision became likely enough to plan for.

The realistic failure mode is not probability but a weak random source. A generator built on Math.random rather than a cryptographic one can and does repeat. This tool uses crypto.randomUUID where the browser provides it and crypto.getRandomValues everywhere else, both of which are cryptographically secure.

Version 7 spends 48 of its bits on the timestamp, four on the version, two on the variant and twelve on the counter, which leaves 62 random. That is a smaller number and still an enormous one: two ids generated independently inside the same millisecond collide with a probability of roughly one in 4.6 quintillion.

The nil UUID is all 128 bits zero, and it is the conventional way to say “no identifier here” in a column or protocol field that has to hold a UUID regardless. It is a real, specified value rather than a hack — but treat it as a sentinel, never as an id you assign to something.

The max UUID, all bits one, was added in RFC 9562 as its counterpart. Its practical use is as an upper bound: a range scan over a UUID-keyed index needs a value that sorts above every possible key, and this is it.

Neither carries a meaningful version or variant, because every bit is fixed. The inspector recognises both by name rather than pretending the zero nibbles mean version 0.