ULID Generator
Generate sortable, time-based ULIDs.
What is a ULID?
A ULID (Universally Unique Lexicographically Sortable Identifier) is a 26-character ID encoded in Crockford's Base32: a 48-bit millisecond timestamp in the first 10 characters, then 80 bits of randomness. Because the timestamp leads, sorting ULIDs as plain strings sorts them by creation time — which is the property that makes them useful as database keys, where a random UUID scatters inserts across the index.
Monotonic is what makes that true within a millisecond. Date.now() has millisecond resolution, so a batch generated in a loop lands many IDs in the same millisecond and shares one timestamp prefix; their order would then be decided purely by the random component, which is to say not ordered at all. With monotonic on, an ID minted in the same millisecond as the last one increments the previous random value instead of drawing a new one, so the batch above is strictly increasing and the “Ordered” badge is checking the real output, not the setting. Turn it off if you would rather the IDs not reveal how many were minted in sequence.
Crockford's alphabet omits I, L, O and U, so a ULID cannot be misread or mistyped between 1/I or 0/O. Randomness comes from crypto.getRandomValues, and everything is generated in your browser.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Producing an identifier that sorts by creation time as well as being unique.
- Generating a primary key with index locality that a random UUID destroys.
- Producing ids client-side that will still order correctly server-side.
- Creating identifiers for an event log where ordering matters.
- Generating a key that is shorter and more URL-friendly than a UUID.
Frequently Asked Questions
- What is a ULID made of?
- 26 characters: 10 encoding a 48-bit millisecond timestamp, then 16 encoding 80 bits of randomness, all in Crockford's base32. Because the timestamp comes first and base32 preserves order, lexicographic sort equals chronological sort — the property a UUIDv4 has no way to offer.
- What does monotonic mode change?
- Behaviour within a single millisecond. Several ULIDs generated in the same millisecond share a timestamp, so their order would otherwise be random; monotonic mode increments the random component instead of redrawing it, guaranteeing the sort holds even for a burst.
- Why does that matter for a batch?
- Because it is exactly where the naive implementation fails. Taking one timestamp for the whole batch and giving each ID an independent random suffix means every ID shares a prefix and the order is chance — measured, one batch of five in 200 came out sorted, which is precisely 1 in 5!.
- Why Crockford's base32 rather than hex or base64?
- It excludes I, L, O and U — the characters most often misread or, in U's case, capable of forming unintended words — and it is case-insensitive on input. That makes a ULID safe to read aloud and retype, which base64 with its case-sensitive alphabet is not.
- ULID or UUIDv7?
- They solve the same problem and UUIDv7 is now the standardised answer (RFC 9562), which makes it the better default for anything new — native database types, existing tooling. ULID's advantages are its shorter text form and the base32 alphabet; the underlying idea is identical.
Common errors and gotchas
- Treating the timestamp as trustworthy, since it comes from the generating client's clock.
- Assuming strict monotonicity within a millisecond, which needs an implementation that guarantees it.
- Exposing the id publicly and leaking creation times you did not intend to publish.
- Confusing the Crockford base-32 alphabet with standard base-32, which differ.
- Expecting case sensitivity, when the encoding is deliberately case-insensitive.