A Universally Unique Lexicographically Sortable Identifier: 128 bits written as 26 Crockford base32 characters. The first 10 characters are a 48-bit Unix timestamp in milliseconds; the last 16 are 80 random bits. Because the timestamp comes first, sorting ULIDs as plain strings sorts them by creation time.

What does the monotonic option do?

If two ULIDs are generated in the same millisecond, the spec lets you keep the same timestamp and increment the previous random part by one rather than drawing new randomness. That guarantees strictly increasing order within a batch. It is optional in the spec; turn it off if you want every random part to be independent.

Is a ULID a good choice for a database primary key?

Often yes, because new rows land near the end of the index, which is kinder to B-tree inserts than a fully random UUID v4. The tradeoff is that the ID reveals its creation time to anyone who can see it, and the first 48 bits are predictable, so never use a ULID as a secret token.

How is a ULID different from UUID v7?

Both put a millisecond timestamp first. UUID v7 (RFC 9562) is a standard UUID with 74 random bits and the usual 36-character hex format, so it fits UUID columns and libraries. A ULID has 80 random bits, is shorter at 26 characters, and uses its own base32 text form, so tooling that validates UUIDs will not accept it.

ULID Generator

Generate 1–100 ULIDs in your browser: 26-character, time-sortable Crockford base32 IDs per the ULID spec, with each timestamp decoded. Nothing is uploaded.

Loading tool…

Worked examples

A single ULID
One 26-character identifier whose first 10 characters encode the current time, so it sorts after every ULID made earlier.
A monotonic batch of 10
Ten ULIDs generated back to back; any made in the same millisecond share a timestamp prefix and strictly increase, so the batch stays in sorted order.
Independent random parts, no monotonic guarantee
Each ULID draws a fresh 80-bit random part. Within one millisecond the order between ULIDs is then arbitrary, though the timestamp prefix still sorts correctly across milliseconds.

What this tool does

This tool generates ULIDs (Universally Unique Lexicographically Sortable Identifiers) in your browser and shows the creation time hidden inside each one. A ULID looks like 01M4BJE4F1XQCKWF9MDQSP728X: 26 characters that encode 128 bits. You can generate 1 to 100 at a time, with or without the optional monotonic guarantee.

When you need it

You want primary keys that are unique without coordination but still insert near the end of an index, instead of landing at random spots the way UUID v4 values do.
You need IDs that sort by creation time as plain strings, for example in S3 or DynamoDB keys, log lines or event streams.
You are checking what time a ULID in your database encodes. The second output lists every ID next to its decoded UTC timestamp.
You want a shorter, copy-friendly alternative to a 36-character UUID.

How a ULID is built

The ULID spec splits the 128 bits into two parts. The first 48 bits are a Unix timestamp in milliseconds, written as the first 10 characters. The remaining 80 bits are random, written as the last 16 characters. Both parts use Crockford's base32 alphabet, 0123456789ABCDEFGHJKMNPQRSTVWXYZ, which leaves out I, L, O and U so IDs are harder to misread and cannot spell most accidental words.

Because the most significant part comes first and base32 characters sort in the same order as their values, comparing two ULIDs as strings compares their timestamps. That is the whole trick behind "lexicographically sortable". It also explains the one odd-looking rule in the spec: the first character can never be higher than 7, because 48 bits do not fill 50 bits of base32. The largest valid timestamp is in the year 10889.

What the monotonic option does

Two ULIDs created in the same millisecond have the same 10-character prefix, so their order depends on the random part, which is arbitrary. The spec's answer is monotonicity: when you generate another ULID within the same millisecond, keep the same timestamp and add one to the previous random value. With the option on, this tool does exactly that, carrying the increment across digits and failing with an error in the astronomically unlikely case that the 80-bit value overflows. IDs in a batch then come out in strictly increasing order. Generate 100 and look at the end of any run that shares a timestamp: the last character steps through the alphabet in order, G, H, J, K, M, N, carrying into the next digit after Z (I and L do not exist in the alphabet).

With the option off, every ULID draws 80 fresh random bits. Order across different milliseconds is still correct. Monotonicity here applies within one batch you generate on this page, not across separate visits or machines, so it cannot give you a global order.

Where the randomness comes from

The random bits come from crypto.getRandomValues, the browser's cryptographically secure generator, not Math.random(). Each byte is masked to 5 bits, which is unbiased because 256 divides evenly by 32. The timestamp comes from your device clock, so a wrong clock produces ULIDs that sort wrongly; the decoded column makes that easy to spot.

ULID, UUID v7 or NanoID

UUID v7 (RFC 9562) is the closest cousin: a millisecond timestamp first, then random bits, but inside the standard 36-character UUID format that UUID columns and validators understand. A ULID is shorter and has 80 random bits against 74, but it is not a UUID. NanoID is purely random and has no time component. If your database has a native UUID type, v7 is usually the smoother fit; if IDs appear in URLs or you are free of UUID constraints, ULIDs are compact.

Things to know

A ULID reveals when it was created to anyone who sees it. Do not use one where that matters.
The first 48 bits are predictable, so never treat a ULID as a secret token.
Output is uppercase, the canonical form. The spec describes the encoding as case insensitive.
Because the output is random, the example inputs on this page show settings, not fixed results.

Frequently asked questions

What is a ULID?: A Universally Unique Lexicographically Sortable Identifier: 128 bits written as 26 Crockford base32 characters. The first 10 characters are a 48-bit Unix timestamp in milliseconds; the last 16 are 80 random bits. Because the timestamp comes first, sorting ULIDs as plain strings sorts them by creation time.
What does the monotonic option do?: If two ULIDs are generated in the same millisecond, the spec lets you keep the same timestamp and increment the previous random part by one rather than drawing new randomness. That guarantees strictly increasing order within a batch. It is optional in the spec; turn it off if you want every random part to be independent.
Is a ULID a good choice for a database primary key?: Often yes, because new rows land near the end of the index, which is kinder to B-tree inserts than a fully random UUID v4. The tradeoff is that the ID reveals its creation time to anyone who can see it, and the first 48 bits are predictable, so never use a ULID as a secret token.
How is a ULID different from UUID v7?: Both put a millisecond timestamp first. UUID v7 (RFC 9562) is a standard UUID with 74 random bits and the usual 36-character hex format, so it fits UUID columns and libraries. A ULID has 80 random bits, is shorter at 26 characters, and uses its own base32 text form, so tooling that validates UUIDs will not accept it.