Generate ULIDs, Sortable IDs With a Timestamp Built In
This ulid generator creates ULIDs (Universally Unique Lexicographically Sortable Identifiers), a sortable unique id generator format that packs a millisecond timestamp into the first 10 characters and 80 bits of cryptographically random data into the remaining 16, all encoded as a single 26-character, URL-safe string. As a lexicographically sortable id generator, it means a list of ULIDs sorted as plain strings (alphabetically) automatically comes out in creation order too, no separate created_at column needed just to sort by when a row was inserted.
How to Use This ULID Generator
Set Count to how many IDs you need (1 to 100 per request), and optionally set a Timestamp override (ISO 8601, e.g. 2026-01-01T00:00:00Z) to control the time-encoded portion, useful for generating test fixtures with a specific, reproducible timestamp rather than "now". Leave it blank and every ID uses the current time. Click Generate to generate ulid output instantly, then copy the list or download it as a text file.
ULID vs UUID: What's Actually Different
The ulid vs uuid question comes up constantly since they solve the same problem, here's the actual comparison:
| ULID | UUID v4 | |
|---|---|---|
| Sortable by creation time | Yes, string-sortable | No, fully random |
| Length | 26 characters | 36 characters (with hyphens) |
| Encoding | Crockford Base32 | Hexadecimal |
| Case sensitivity | Case-insensitive (canonically uppercase) | Case-insensitive (canonically lowercase) |
| Randomness | 80 bits | 122 bits |
| Standard | Community spec (ulid/spec on GitHub) | RFC 9562 |
How ULID Encoding Actually Works
As a crockford base32 id generator, the first 10 characters encode a 48-bit millisecond timestamp (enough to represent dates far past the year 10000), and the last 16 characters encode 80 bits of randomness, both using Crockford's Base32 alphabet, which deliberately excludes I, L, O, and U to avoid confusing them with 1, 1, 0, and V when read aloud or copied by hand. Because the timestamp portion is only precise to the millisecond, two ULIDs generated in the exact same millisecond aren't guaranteed to sort correctly relative to each other, only the 80 random bits differ between them, so treat sub-millisecond ordering as unspecified rather than relying on it.