UUID Generator

A v4 UUID has 122 random bits; six are fixed to mark the version and variant. That is about 5.3 undecillion possible values.

The number that actually matters is the birthday bound, not the total space. You would need to generate around a billion UUIDs per second for roughly 85 years before the chance of a single collision reached about 50 percent. For any application you are likely to build, the probability is not small - it is negligible in a way that other parts of your system are not.

That holds on one condition: the randomness has to be good. A generator using a weak or badly seeded random source can produce collisions far sooner than the maths suggests, and that has happened in real systems. This one uses the browser's cryptographic random source, which is the right one.

v4 is random and the default choice for most purposes.

v1 encodes a timestamp and the machine's MAC address. It sorts by creation time, which is useful, and it leaks which machine created it and when, which historically has been an information disclosure problem.

v5 is deterministic: hash a namespace and a name and you get the same UUID every time. Useful when you want a stable identifier derived from something you already have.

v7, standardised in 2024, is the interesting one. It puts a millisecond timestamp in the high bits and random data in the rest, so it is both unpredictable and sortable by creation time. That combination fixes the main practical complaint about v4, which is described below.

This tool generates v4 only. If you are choosing identifiers for a new database table, v7 is worth looking at.

v4 UUIDs make poor primary keys in a table with a clustered index, and the reason is worth understanding before you commit a schema.

Sequential integers append at the end of the index. Every insert lands in the same page, which stays in memory, and the index grows tidily.

Random UUIDs land anywhere. Every insert touches a different part of the index, which means more pages read from disk, more page splits, and an index that fragments as it grows. On a large, write-heavy table the difference is measurable.

The usual answers are to use a time-ordered variant like v7, or to keep an internal sequential key and expose a UUID separately. Which is often what you wanted anyway - the reason to expose UUIDs publicly is that sequential ids tell the world how many records you have and let anyone walk them.

The canonical form is 8-4-4-12 hex digits with hyphens, lower case. The specification says generators should emit lower case and parsers should accept either, which is exactly the kind of asymmetry that produces bugs when one system compares strings and another does not normalise first.

Stored as text a UUID is 36 characters. Stored as binary it is 16 bytes. Databases with a native UUID type use the compact form, and using a character column instead costs more than double the space plus slower comparisons - a common and avoidable mistake.

The all-zero UUID is the nil UUID and is a valid, reserved value. It usually means uninitialised, and treating it as a real identifier is another quiet source of bugs.