UUID vs NanoID vs ULID

Four Flavors of Unique ID

UUID v4 (random)

122 bits of randomness, 36-character string. Ubiquitous, well-supported in every language and database. Downsides: non-sortable, large (16 bytes binary / 36 bytes string), and fragments B-tree indexes because random values scatter inserts across pages.

UUID v7 (time-ordered)

Combines a millisecond timestamp with randomness in a UUID-compatible layout. Monotonically increasing within the same millisecond, so inserts cluster at the end of the index — kinder to Postgres and MySQL B-trees than v4. Standardized in RFC 9562 (2024).

NanoID

21-character URL-safe string, 126 bits of entropy — about the same collision resistance as UUID v4 in less space. Great for public URLs (shorter than UUID) but non-sortable like v4.

ULID

26-character Crockford Base32 string with a 48-bit millisecond timestamp prefix and 80 random bits. Lexicographically sortable, URL-safe, slightly shorter than UUID. Great for logs and event IDs.

Which to Pick

• Primary keys in a RDBMS: UUID v7 (or ULID stored as 16-byte binary)
• Public URLs: NanoID (short) or ULID (sortable)
• Legacy compatibility: UUID v4 — everyone speaks it
• Distributed logs / events: ULID or UUID v7
• Short share codes: NanoID with a custom alphabet and length

Try It

Encode or decode a UUID to compact Base64 with our free UUID ↔ Base64 converter.