ULID Generator

Generate ULIDs in bulk — sortable, time-ordered identifiers that work as a drop-in alternative to UUIDs.

Usage Tips

  • The first 10 characters of a ULID encode a timestamp (the creation time), while the remaining 16 are random. Except when two ULIDs are generated within the same millisecond, a simple string sort will put them in creation order.
  • Using a fully random UUID v4 as a database primary key tends to fragment B-tree indexes, since new rows get inserted at random positions. Because ULIDs sort roughly by time, new rows land near the end of the index, which helps mitigate this issue.
  • A ULID is represented as 26 characters of Crockford's Base32 (the 32-character alphabet `0`-`9` and `A`-`Z` with the easily confused I, L, O, and U removed), making it shorter than a UUID (36 characters including hyphens) and safe to use in case-insensitive environments.
  • For a side-by-side comparison with Nano ID and UUID v4, see the comparison table on our sister tool, the Nano ID Generator page.

Frequently Asked Questions

A ULID (Universally Unique Lexicographically Sortable Identifier) is a specification for identifiers that, like a UUID, are globally unique, but also embed creation-time information — meaning a plain string sort will arrange them in chronological order.

The main difference is whether the identifier can be sorted by creation time. UUID v4 is a fully random 128-bit value, so it can't be sorted by creation order, whereas a ULID's first 48 bits are a millisecond-precision timestamp, so a simple string comparison reveals the creation order. There's also a formatting difference: a ULID is 26 characters of Base32, while a UUID is 36 hexadecimal characters including hyphens.

Using a fully random value like UUID v4 as a primary key means new rows get inserted at random positions within the index, which can lead to B-tree index fragmentation and reduced cache efficiency. Because ULIDs sort roughly by time, new rows tend to be appended near the end of the index, which is said to help mitigate this problem.

The first 10 characters are a 48-bit millisecond timestamp (able to represent dates up to roughly the year 10889), and the remaining 16 characters are 80 bits of randomness. In total that's 128 bits — the same as a UUID — but with creation-time information built in, which is ULID's defining feature.
ツールくん

Side Note — How ULID Brought Chronological Order to the World of IDs

The ULID specification was published in 2016 by Alizain Feerasta. At the time, UUID was already the standard way to generate unique IDs in distributed systems, but its fully random nature — which made it impossible to sort — was seen as inconvenient for database index efficiency and for time-series analysis of logs. ULID was created to address exactly that problem.

UUID does actually have time-based variants of its own: version 1 (a MAC address plus a timestamp) and version 7 (standardized in 2024, combining a timestamp with random bits). ULID, however, is an independent specification distinct from the UUID standard (RFC 4122), and it distinguishes itself by pursuing a simpler design along with a compact Base32 representation.

Today, implementation libraries for ULID exist in nearly every major programming language, and it is widely adopted wherever preserving creation order matters — event IDs in distributed systems, trace IDs in logs, and database primary keys among them. Its design philosophy overlaps considerably with UUID v7, which emerged around the same time, and the two now coexist as different approaches to the same goal: a sortable, UUID-like identifier.

More tools in this category