UUID Generator

What the 32 digits are holding

A UUID is 128 bits, written as 32 hexadecimal digits in the 8-4-4-4-12 pattern that makes it 36 characters with the hyphens. Two small regions of those bits are not payload. Four bits say which version generated it, and two or three more mark the variant, which says whose layout rules apply. That leaves 122 bits for a version 4 UUID to be random in.

The version nibble is the thirteenth hex digit — the one right after the second hyphen. In a v4 UUID it is always 4, which is why so many UUIDs you see have a 4 sitting in that position. The variant shows up as the seventeenth digit being 8, 9, a or b. Those two facts are all the inspector above is really doing.

v4 or v7

Version 4 is pure randomness and has been the sensible default for twenty years. Version 7 was standardised in RFC 9562 in 2024, alongside v6 and v8, replacing the older RFC 4122. It puts a 48-bit Unix timestamp in milliseconds at the front and fills the rest with random bits.

The reason to care is database indexes. A v4 primary key lands at a random point in the index on every insert, so the database is constantly splitting pages it has not touched recently and reading them back from disk. A v7 key appends, because each new value is larger than the last, so inserts concentrate on the pages already in memory. On a table with millions of rows this is the difference between an index that fits in cache and one that does not.

The cost of v7 is that it tells everyone when the row was created, to the millisecond. If the identifier is public and the creation time is not something you want published — an order ID that reveals your sales rate, for instance — that is a real leak, and v4 is the right choice.

Collisions, and why nobody worries about them

With 122 random bits, you would need to generate roughly 2.7 quintillion v4 UUIDs before reaching a 50% chance of a single collision anywhere in the set. That is the birthday bound, not a guarantee, and it holds only if the bits are genuinely random. This tool takes them from crypto.getRandomValues, the browser's cryptographic generator.

The failure mode that actually happens is a bad random source. Several older JavaScript libraries built UUIDs out of Math.random, which is fast, predictable and never intended for this. Those UUIDs look identical to good ones — the version nibble is still a 4 — and no inspector can tell them apart. If you inherited a codebase generating UUIDs by hand, that is worth checking.

Do not use a UUID as a secret

A v4 UUID has enough entropy to be unguessable, so the temptation to use one as a password reset token or an unlisted share link is understandable. Two problems. Anything below v4 is not random at all — a v1 UUID exposes a timestamp and often a MAC address, and v3 and v5 are hashes of a name you may be able to guess. And UUIDs are treated as identifiers throughout most systems, which means they end up in logs, in analytics, in Referer headers and in support tickets. Generate tokens with a tool meant for secrets.

Storing them

A UUID is 16 bytes. Stored as CHAR(36) it takes 36, and every index on it grows accordingly. PostgreSQL has a native uuid type that stores the real 16 bytes; MySQL does not, so BINARY(16) with conversion at the edges is the usual answer. Keep the text form lowercase and hyphenated, because that is the canonical representation and mixed casing turns equality comparisons into a bug hunt.

What this tool does not generate

• v3 and v5. Both hash a namespace UUID together with a name to produce the same output every time for the same input. That is a different shape of tool, needing two inputs rather than a count.
• v1. It needs a node identifier, and a browser has no access to a MAC address. A v1 UUID with a random node is just a worse v7.
• Strictly ordered v7. RFC 9562 allows an optional counter so that UUIDs made inside the same millisecond still sort correctly. This one fills those bits with randomness instead, which is compliant but means a batch of 1000 generated in a single millisecond has no internal order. Across milliseconds the ordering is exact.

The inspector has a limit worth naming too: it reads bits and nothing else. Any 32 hex digits with a plausible version and variant will be reported as a valid UUID, because that is all a UUID is. It cannot tell you whether the thing was generated properly, or whether it means anything in your system.

Last updated September 19, 2026