UUID Generator

Which UUID version do you need?

A UUID is a 128-bit identifier you can generate anywhere without a central server and still expect to be unique. The version number says how it's built:

This tool produces v4, the right choice for most uses. The odds of two v4 UUIDs colliding are so small you can ignore them in practice.

Reading a UUID

Take 3f2504e0-4f89-41d3-9a0c-0305e82c3301. The first digit of the third group (4) is the version, so this is a v4 (random) UUID. The first digit of the fourth group (9) is the variant field and is normally 8, 9, a or b. So you can identify any UUID's type from that one version digit.

Generating UUIDs in code

// JavaScript (modern browsers & Node)
crypto.randomUUID();   // v4

# Python
import uuid
uuid.uuid4()           # random
uuid.uuid1()           # time + node

If you are choosing identifiers for a high-write database table, reach for v7 rather than v4: its millisecond time prefix keeps values increasing, so new rows append neatly to the index instead of landing in random positions.

From v1's privacy leak to v7

The UUID versions are a small history of fixing each other's mistakes. v1 encodes a timestamp and the machine's MAC address, which makes it sortable but means a UUID can quietly reveal which computer made it and when — a real privacy leak that surfaced in a famous malware investigation. v4 threw all that out for pure randomness, which fixed the leak and became the default, at the cost of being completely unordered. v7, standardized in 2024's RFC 9562, is the modern compromise: a millisecond timestamp at the front for ordering, random bits for the rest for uniqueness. For most application code v4 is still the right, boring choice; v7 is the one to know about the moment UUIDs become database keys.

Why random UUIDs hurt as primary keys

This is the practical reason v7 exists. A v4 key is random, so each new row lands at a random spot in the table's primary index. On a clustered index — InnoDB in MySQL is the usual victim — that means constant page splits and a cache that's forever thrashing, and on a large, write-heavy table the slowdown is very real. A v7 key increases over time, so new rows append to the end of the index the way an auto-increment integer would, keeping inserts fast while still letting you generate IDs anywhere without a central counter. Storage matters too: a UUID kept as a 36-character string is wasteful next to the 16 bytes it really is, so high-volume tables store it as BINARY(16) (or Postgres's native uuid type) and save both space and index size.

One more judgement call: UUIDs make poor user-facing identifiers. They're long, ugly in a URL, and impossible to read over the phone. If humans will see or type the ID, a shorter scheme is kinder; keep UUIDs for internal and system-to-system use where their "generate anywhere, never collide" property is what you actually want.