Use the free ULID Generator below: your data never leaves your browser — all work happens on your device, and nothing is uploaded to any server.
ULID: the ID that sorts itself
ULIDs were created to fix one annoyance with UUIDs: UUIDs do not sort in creation order. If you use random UUIDs as database keys, new rows scatter randomly through the index, which hurts performance. ULIDs solve this by putting a timestamp first. A ULID is 26 characters long: the first 10 encode the creation time in milliseconds, and the remaining 16 encode randomness. Because the timestamp comes first and the encoding preserves numeric order, ULIDs sort chronologically as plain strings. Newer records naturally land after older ones.
The encoding is Crockford base32, an alphabet of digits and letters chosen to be readable and unambiguous. It excludes I, L, O and U, because I looks like 1, L looks like 1, O looks like 0, and U was dropped to avoid accidentally forming rude words. It also treats lowercase input as uppercase, so case does not matter. The result is an ID that is shorter than a UUID at 26 characters, URL-safe, and safe to read aloud over the phone without confusion.
How a ULID is built
Take the current time in milliseconds since 1 January 1970. Encode it in base32 using the Crockford alphabet, padded to 10 characters. That is the time part, and it covers dates up to the year 10889, so it will not run out. Then generate 80 bits of randomness, from a cryptographic random source, and encode those as 16 base32 characters. Join the two parts and you have a ULID. Two ULIDs created in the same millisecond share the time part and differ in the random part, so they are still unique, though their order within that millisecond is random rather than sequential.
This tool generates ULIDs with your browser’s crypto.getRandomValues, which is a proper cryptographic random source, and it can decode any ULID back to its creation time. Paste a ULID and you get its timestamp in milliseconds plus the date in UTC. That is handy for debugging: a ULID found in a log tells you exactly when the record was created, to the millisecond, without any database lookup.
ULID versus UUID: which to choose
Choose ULIDs when sort order matters. Database primary keys, log entries, event streams and message queues all benefit from chronological ordering, because range queries and “latest first” listings become cheap. Choose UUIDs, specifically version 4, when you need maximum unpredictability or when you must interoperate with systems that expect the UUID format. ULIDs are also slightly more compact and friendlier to humans, while UUIDs have broader tooling and a longer track record.
There are trade-offs to know. A ULID’s timestamp is visible to anyone who reads it, so it leaks creation time, just like UUID version 1 and 7. If that matters, use a random UUID instead. ULIDs also have 80 bits of randomness rather than 122, which is still far more than enough for any real system, but it is a smaller margin. And ULIDs are case-insensitive by design, so a system that treats them as case-sensitive strings could theoretically see two spellings of the same ID as different values; normalizing to uppercase avoids that.
Monotonicity, and the same-millisecond question
The ULID specification describes a monotonic mode: when several ULIDs are generated in the same millisecond, the random part is incremented instead of re-randomized, so the order stays strictly increasing. Not every implementation does this, and this tool uses fresh randomness each time, which is simpler and still unique. For most uses, fresh randomness is fine. If you need a strict guarantee that every generated ID sorts after the previous one, use a library that implements monotonic generation, and generate IDs through a single instance rather than across many machines.
One more practical note: ULIDs are 26 characters, but they encode 128 bits, the same as a UUID. Nothing is lost in the shorter string; base32 is simply more compact than hex. That is why ULIDs feel modern: same information, less clutter, plus ordering for free.
Common questions
Can a ULID be used as a database primary key? Yes, and that is one of its main uses, especially in databases where string keys sort well. Is a ULID guessable? Partly: the timestamp is predictable, but the 80 random bits are not, so the full ID cannot be guessed. Why no I, L, O or U? To avoid characters that look alike or form accidental words. Is generation done locally? Yes. Everything runs in your browser, and nothing is sent anywhere.