UUID, ULID and UUIDv7 generator and decoder

UUID versions and ULID, compared

A UUID is 128 bits written as 32 hex digits in five groups: 8-4-4-4-12. The first digit of the third group is the version, and the first digit of the fourth group holds the variant. Everything else depends on the version.

UUID v4 is 122 random bits. It is the safe default when you only need uniqueness. UUID v7, standardised in RFC 9562 in 2024, puts a millisecond Unix timestamp in the first 48 bits and fills the rest with random data. Because v7 IDs sort by creation time, they keep B-tree indexes compact, so they work better than v4 as primary keys.

ULID uses the same idea, a 48-bit timestamp plus 80 random bits, but writes it as 26 characters of Crockford base32. It is shorter, case-insensitive and URL-safe, but most databases have no native type for it. UUID v1 is older: a 60-bit timestamp counted in 100 ns steps since 1582, plus a node ID that was often the machine’s MAC address.

Common mistakes

1. 01Using v4 as a clustered primary keyRandom keys insert all over the index, which causes page splits and cache misses at scale. v7 or ULID insert in order.
2. 02Treating a v7 timestamp as secretAnyone can read the creation time from a v7 ID or ULID. Use v4 for IDs that are shown publicly and should not reveal when something was created.
3. 03Comparing IDs as case-sensitive stringsUUIDs are case-insensitive. Normalise to lowercase before comparing, or store them in a native uuid column.
4. 04Generating IDs with Math.randomIt is not cryptographically secure and can collide. Use crypto.randomUUID() or crypto.getRandomValues.