ULID Generator
Lexicographically sortable identifiers: 48-bit timestamp plus 80 random bits.
What a ULID is
A ULID is 128 bits written as 26 characters: a 48-bit millisecond timestamp followed by 80 random bits, encoded in Crockford's base32. Because the timestamp comes first and base32 sorts the same way the underlying number does, sorting ULIDs as plain strings sorts them by creation time. That is the whole point, and it is a property a UUID v4 does not have.
ULID or UUID v7?
They solve the same problem, and if you are choosing today, choose UUID v7. It is time-ordered in exactly the same way, but it is standardised in RFC 9562, which means your database, your language's standard library and your ORM are likely to support it natively — PostgreSQL, for instance, stores a UUID in 16 bytes rather than the 26 characters a ULID costs as text. ULID's advantages are that it predates v7 and that its base32 form is friendlier to read and to double-click: no hyphens, no ambiguous characters, since Crockford's alphabet drops I, L, O and U to survive being read aloud. Pick ULID when you have one already, or when identifiers are meant to be handled by people. Pick v7 for anything new that lives in a database.
The trade-off you are accepting
Both formats leak their creation time to anyone holding one — that is not a flaw, it is the feature — so neither belongs in a password-reset link or anywhere the timestamp is sensitive. Use a v4 UUID there. Note also that ULIDs generated in the same millisecond have no defined order between them; the specification describes a monotonic counter for that case, which this generator does not implement, because it matters only when you need a strict order within a single millisecond from a single process.
ULID or UUID v7?
For anything new that lives in a database, UUID v7: it is time-ordered in the same way but standardised in RFC 9562, so your database, standard library and ORM likely support it natively — and PostgreSQL stores it in 16 bytes rather than the 26 characters a ULID costs as text. Choose ULID when you already have one, or when identifiers are handled by people: no hyphens, and Crockford's alphabet drops I, L, O and U.
Are ULIDs sortable?
Yes — that is the whole point. The 48-bit millisecond timestamp comes first, and Crockford base32 sorts the same way the underlying number does, so sorting ULIDs as plain strings sorts them by creation time. Two generated in the same millisecond have no defined order between them unless you implement the spec's monotonic counter, which this generator does not.
Can I use a ULID as a secret?
No. Only 80 of its 128 bits are random, and the other 48 are a timestamp anyone can guess. It is an identifier, not a secret. If a value needs to be unguessable, use a hex or base64 secret — or a UUID v4, whose 122 bits are all random.
Nothing leaves your browser
- Don't take our word for it — turn off your wifi. Every generator on this site keeps working with the network disconnected. That's the whole proof, and it takes five seconds.
- Every value comes from
crypto.getRandomValues()— the CSPRNG built into your browser, neverMath.random(). - Generated secrets are never transmitted, logged or stored: no server-side generation, no cookies, no localStorage.
- Verify it yourself in the network tab: after loading, the page only talks to our self-hosted, cookie-less analytics — which counts page views and which generator type gets copied, never any value.
- Strict Content-Security-Policy; no third-party script origins.