UUIDs solve uniqueness but sacrifice sortability — a random UUID tells you nothing about when it was created. ULID was designed specifically to fix that, and this tool generates them.
A newer identifier built to fix a specific UUID complaint
The ULID (Universally Unique Lexicographically Sortable Identifier) specification emerged around 2016 from an open-source project explicitly responding to a recurring frustration with standard random UUIDs: because they're generated with no time component, inserting them as a database primary key or index tends to produce poor performance, since new records scatter randomly throughout the index rather than appending in order. ULID solves this by encoding the current timestamp (in milliseconds) into the first part of the identifier, followed by random data for the remainder — meaning ULIDs generated later always sort after ones generated earlier, purely through simple string comparison, while retaining strong collision resistance from their random component.
How this tool generates a ULID
The tool encodes the current Unix timestamp in milliseconds into the first 48 bits, then fills the remaining 80 bits with cryptographically random data, and represents the full 128-bit result using Crockford's Base32 encoding — a deliberately chosen alphabet that excludes visually ambiguous characters like I, L, O and U to reduce transcription errors, producing a 26-character identifier that's both URL-safe and case-insensitive.
Where ULIDs offer a genuine advantage over standard UUIDs
- Database primary keys with better index performance — because ULIDs are naturally sortable by creation time, using them as a primary key avoids the index fragmentation problem that purely random UUIDs cause in many database engines.
- Event logs and time-series data — systems that need both a globally unique identifier and a natural chronological ordering (like event sourcing architectures) benefit directly from ULID's built-in timestamp encoding.
- Distributed systems needing rough time ordering — services that generate records across multiple independent nodes can use ULIDs to get an approximate, decentralized sense of creation order without needing a centralized sequence.
- Replacing UUIDs where sort order matters — any system already using random UUIDs purely as unique keys, where the lack of natural ordering is a genuine pain point, is a good candidate for switching to ULID.
Frequently asked questions
Is a ULID as collision-resistant as a UUID? Effectively yes for practical purposes — ULID's 80 bits of randomness (versus a UUID v4's 122) still provide an extremely low collision probability, especially since collisions would require two ULIDs to be generated within the exact same millisecond with identical random data, an already rare combination.
Why does ULID use Base32 instead of hexadecimal like UUID? Base32 encoding packs more information per character than hexadecimal, producing a shorter 26-character string instead of a UUID's 36-character hyphenated form, while Crockford's specific Base32 alphabet also avoids visually confusable characters, making ULIDs somewhat friendlier to read, type or communicate verbally.
Does the timestamp in a ULID reveal sensitive information? It reveals the approximate creation time of the record, which is worth considering in contexts where hiding exactly when a resource was created matters for privacy or security reasons — a genuine tradeoff against the sortability benefit that's worth evaluating case by case.
Further reading
ULID Specification — The official open-source specification defining ULID's structure and encoding.
Wikipedia — UUID — Background on the standard UUID format that ULID was designed to improve upon for sortability.