What a UUID is
A UUID is a 128-bit identifier you can make anywhere, without asking a database for the next number. It's written as 32 hex digits in five groups, like 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. The first digit of the third group is the version, and the first digit of the fourth group holds the variant (8, 9, a or b for every UUID made today). RFC 9562, published in 2024, is the current standard; it replaced RFC 4122 and added versions 6, 7 and 8.
UUID v4: random
Version 4 is 122 random bits plus the 6 bits that mark the version and variant. It says nothing about when or where it was made, which is what you want for anything that shouldn't be guessable from another ID. In code it's one call: crypto.randomUUID() in browsers, Node, Deno and Bun, anduuid.uuid4() in Python.
UUID v7: sortable by time
Version 7 starts with the Unix time in milliseconds (48 bits) and fills the rest with random bits. Because new IDs are always larger than old ones, they go to the end of a B-tree index, which keeps inserts fast and pages full, unlike v4, which scatters writes across the whole index. Sorting by ID also sorts by creation time. This tool makes each batch strictly increasing, even inside one millisecond, by using the 12 bits after the version as a counter (RFC 9562 section 6.2, method 1).
The catch: anyone holding a v7 can read when it was made. Postgres 18 can make them natively with uuidv7(); elsewhere use a library.
ULID
A ULID has the same idea as v7, a 48-bit millisecond time followed by 80 random bits, but it's written in 26 characters of Crockford base32:01ARZ3NDEKTSV4RRFFQ69G5FAV. It skips I, L, O and U so it can be read aloud and typed without mix-ups, and it sorts correctly as plain text. It predates v7 and isn't a UUID, so use it where you control the column type.
The other versions
- v1 holds a timestamp and the machine's MAC address. Avoid it: it leaks which machine made the ID.
- v3 and v5 are hashes (MD5 and SHA-1) of a namespace and a name, so the same input always gives the same UUID.
- v6 is v1 with the timestamp reordered so it sorts. New systems should use v7 instead.
- v8 is a free-form layout for custom schemes.
The inspector reads all of them, and shows the time inside v1, v6, v7 and ULIDs.
FAQ
Should I use UUID v4 or v7?
Use v7 for database primary keys and anything you sort or page through: it starts with a timestamp, so new rows land at the end of the index instead of all over it. Use v4 when the ID shouldn't reveal when it was made, such as a token in a URL.
Are these UUIDs really random?
Yes. They come from your browser's crypto.getRandomValues, the same source crypto.randomUUID uses. Nothing is generated on a server, and nothing is sent anywhere.
Can two UUIDs ever be the same?
In practice, no. A v4 has 122 random bits: you would need to make about 2.7 quintillion of them for a 50% chance of a single collision. A v7 has 74 random bits per millisecond, and IDs made in different milliseconds can't collide at all.
What's the difference between a ULID and a UUID v7?
Both are 128 bits that start with a millisecond timestamp and sort by time. A ULID is written as 26 characters of Crockford base32, which is shorter and avoids look-alike letters. A UUID v7 is written as 36 hex characters and fits any column or library that expects a UUID.
How do I get the time out of a UUID v7?
The first 12 hex digits are the Unix time in milliseconds. In JavaScript: new Date(parseInt(id.replaceAll('-', '').slice(0, 12), 16)). Or paste it into the inspector on this page.