UUID vs ULID: Which Unique ID Should You Use?
A clear comparison of UUID and ULID — how they differ, when to use each, and the trade-offs in sorting, size and readability.
Both UUID and ULID give you a unique identifier without a central database, but they solve slightly different problems. Here's the short version, then the details.
Quick answer
- Use a UUID (v4) when you just need a random, universally-recognized unique ID and don't care about ordering.
- Use a ULID when you want IDs that sort by creation time and are a bit shorter and URL-friendlier.
The key differences
| UUID (v4) | ULID | |
|---|---|---|
| Length | 36 chars (with hyphens) | 26 chars |
| Sortable by time | No | Yes |
| Characters | Hex + hyphens | Crockford Base32 (no look-alikes) |
| Randomness | 122 random bits | 80 random bits + 48-bit timestamp |
| Recognized everywhere | Yes | Growing |
Why "sortable" matters
A ULID's first 10 characters encode a millisecond timestamp, so if you sort ULIDs as strings, they come out in creation order. That's great for database primary keys — new rows are appended near each other, which is friendlier to database indexes than fully random UUIDs (which scatter writes across the index).
Readability
ULIDs use Crockford Base32, which excludes look-alike characters (no I, L, O, U), so they're less error-prone when read aloud or typed. UUIDs are longer and contain hyphens.
When UUID still wins
- You need maximum compatibility — UUIDs are supported natively by nearly every database and language.
- You specifically don't want the creation time leaking from the ID (a ULID exposes roughly when it was made).
Try both
Generate them instantly:
- UUID Generator — RFC 4122 v4 UUIDs, one or thousands at a time.
- ULID Generator — sortable, 26-character IDs.
Still deciding? For most new apps, ULIDs make excellent primary keys; UUIDs remain the safe, universal default.