Developer Tools
ULID generator.
Generate ULIDs — 26-character identifiers that combine a millisecond timestamp with 80 bits of randomness, encoded in Crockford's Base32. Unlike UUID v4, they sort lexicographically by creation time. Bulk-create up to 100 at a time.
Options
ULIDs
Pick options, then press Generate.
How it's generated
A ULID packs two parts into 128 bits, exactly like a UUID, but encodes them so the string sorts in creation order: a 48-bit timestamp (milliseconds since the Unix epoch, good until the year 10889) followed by 80 bits of cryptographically random data. The whole thing is encoded in Crockford's Base32 alphabet — 32 symbols, excluding the visually ambiguous I, L, O, and U — giving a fixed 26-character, case-insensitive, URL-safe string: 10 characters of timestamp followed by 16 characters of randomness.
Because the timestamp comes first, ULIDs generated later always sort after ones generated earlier when compared as plain strings — useful as a database primary key where UUID v4's pure randomness causes index fragmentation. The random tail still gives 280 (about 1.2 × 1024) possible values per millisecond, so collisions within the same millisecond are astronomically unlikely.
Spec: ulid/spec on GitHub is the canonical reference this generator follows.
Frequently asked questions
How is a ULID different from a UUID v4?
Both are 128-bit identifiers, but a UUID v4 is entirely random, so a set of them sorts in no particular order. A ULID's first 48 bits are a timestamp, so a set of ULIDs sorts lexicographically by the time each one was created — handy for database keys, log IDs, and anything you'll want in chronological order without a separate created_at column.
Does encoding the timestamp leak information?
Yes — anyone who sees a ULID can decode the exact millisecond it was created. That's a deliberate tradeoff for sortability. If creation time must stay private, use a UUID v4 instead.
Are these safe to use as database primary keys?
Yes, that's the main use case ULIDs were designed for. The leading timestamp keeps new rows appended near the end of an index (like an auto-increment integer), while the random tail still gives global uniqueness without a central counter.
Generated entirely in your browser
Every ULID is built locally with crypto.getRandomValues. Nothing is sent to any server, and nothing is logged.