Loading page
About this tool
Generate sortable, unique ULIDs as an alternative to UUIDs.
This ULID generator produces batches of five 26-character ULIDs: a 10-character timestamp encoded from the current millisecond followed by 16 characters of randomness, all in Crockford base32. Because the timestamp comes first and base32 sorts the same way lexicographically as it does numerically, ULIDs generated later always sort after earlier ones — the property that makes them a drop-in alternative to random UUIDs for database keys. Copy the whole batch in one click and paste it straight into a seed file, a test fixture or a schema example.
Open ULID Generator on AltFTool — it loads instantly in your browser.
Open the tool — a first batch of five ULIDs is generated on load and listed one per row under the caption "26-char, time-sortable".
Press New ULIDs for a fresh batch of five: each is 10 Crockford base32 characters encoding the current millisecond followed by 16 random characters.
Press Copy to put all five on the clipboard as newline-separated lines; the button reads Copied for about 1.2 seconds before reverting.
The leading 10 characters encode the millisecond timestamp, so plain string sorting puts identifiers in creation order.
Crockford base32 omits I, L, O and U, so an ID read aloud or copied off a screen cannot be mistyped as a look-alike character.
Each press yields a full batch you can copy as newline-separated lines, rather than one value you have to click repeatedly for.
A ULID is a 26-character identifier made of a 48-bit millisecond timestamp plus random bits, encoded in base32, whereas a UUIDv4 is 36 characters of hex and dashes with no ordering. ULIDs sort chronologically as plain strings and are shorter and URL-safe, which is why they are often chosen for database keys and public-facing IDs.
Ten base32 characters carry the timestamp and 16 carry the randomness, which is 26 total. That layout is the ULID specification's, and the 10-character timestamp field has room well beyond the year 10000, so it will not overflow in practice.
Almost certainly not — the 16 random base32 characters give an enormous space of possible values for any single millisecond, so a collision within one millisecond is vanishingly unlikely. Identifiers created in different milliseconds differ in the timestamp prefix regardless.
No. The random portion here is drawn from the browser's ordinary pseudorandom generator, not a cryptographic one, and the timestamp prefix is readable by anyone who sees the ID. Use a cryptographically secure random source for anything that must be unguessable.