ULID Generator

Generate ULIDs — Universally Unique Lexicographically Sortable Identifiers. A ULID packs a millisecond timestamp and 80 bits of randomness into a 26-character Crockford base32 string that sorts in creation order, making it a friendlier alternative to UUID v4 for database keys. Generate one or many, optionally in strict monotonic order, and decode any ULID back to the time it was created. Randomness comes from your browser's cryptographic generator.

ULIDs

How to use the ULID Generator

Set how many identifiers you need and click generate. Each ULID's first ten characters encode the current time, so a batch generated together shares a common prefix and sorts in order. Tick monotonic when you generate several within the same millisecond and need them to stay strictly increasing — the random part is incremented rather than re-rolled, guaranteeing the sort order holds even at sub-millisecond rates.

To inspect an existing identifier, paste it into the decode box. The tool extracts the 48-bit timestamp from the first ten characters and shows the exact creation time in both UTC and your local zone. Decoding is case-insensitive and tolerant of Crockford's ambiguous letters (I, L, O), so a ULID copied from a log or URL decodes cleanly.

What a ULID is

A ULID is a 128-bit identifier — the same size as a UUID — designed to be sortable. The top 48 bits are a Unix timestamp in milliseconds; the remaining 80 bits are random. It is rendered as 26 characters in Crockford's base32, an alphabet of digits and uppercase letters that deliberately omits I, L, O, and U to avoid confusion with 1, 0, and each other, and to stay free of profanity. The result is URL-safe and case-insensitive.

The sortability is the point. Because the timestamp occupies the most significant bits and base32 preserves byte order, sorting ULIDs as plain strings yields chronological order. That makes them excellent primary keys: unlike random UUID v4, new rows are appended near the end of an index rather than scattered throughout it, which keeps B-tree inserts cheap and improves locality. You also get a free, approximate creation time embedded in every key, with no extra column.

The 80 random bits provide ample collision resistance — over 1024 values per millisecond — so two ULIDs generated independently in the same instant practically never collide. For the rare case where you generate many within one millisecond and need a guaranteed order, the monotonic variant increments the random component instead of regenerating it. Compared with UUID v4, a ULID trades nothing in uniqueness while adding sort order and an embedded timestamp; compared with an auto-increment integer, it can be generated anywhere without coordinating with a database.

Common use cases

  • Database primary keys. Sortable keys that keep index inserts efficient and carry a creation time.
  • Distributed ID generation. Create unique, ordered IDs on any node without a central sequence.
  • Event and log identifiers. Sort records chronologically by ID alone.
  • Replacing UUID v4. Keep 128-bit uniqueness while gaining order and an embedded timestamp.

Frequently asked questions

How is a ULID different from a UUID?
Both are 128-bit identifiers. A UUID v4 is fully random and unordered; a ULID puts a millisecond timestamp in its high bits so it sorts chronologically as a string, and it is encoded in 26 Crockford base32 characters rather than the 36-character hyphenated UUID form. ULIDs keep UUID-level uniqueness while adding sort order.

Are ULIDs guaranteed unique?
Not absolutely, but the 80 random bits make a collision within a single millisecond astronomically unlikely — more than 10^24 possibilities. Across different milliseconds the timestamp differs, so collisions there are impossible. Monotonic mode additionally guarantees ordering for IDs created in the same millisecond.

What does monotonic mode do?
When two ULIDs are generated in the same millisecond, normal mode gives each fresh randomness, so their relative order is random. Monotonic mode instead increments the previous random component by one, guaranteeing the later ID sorts after the earlier one even at very high generation rates.

Is the randomness cryptographically secure?
Yes. The random bits come from the browser Web Crypto getRandomValues generator, the same source used for cryptographic keys, rather than from Math.random. Everything is computed locally; no identifiers are sent anywhere.

Can I recover the creation time from a ULID?
Yes. The first ten characters encode the 48-bit millisecond timestamp, which the decoder reads back exactly. The random portion carries no information beyond uniqueness, so only the timestamp is recoverable.
Embed this tool on your site

Free to embed, no attribution required (but appreciated). Paste this where you want the tool to appear: