Overview
Generate ULIDs: 128-bit identifiers that sort chronologically because their first characters encode a millisecond timestamp. The generator uses Crockford Base32 for URL-safe, unambiguous output and produces batches instantly, entirely in your browser.
How It Works
Set how many ULIDs you want, from 1 to 100, with 5 as the default, and press the generate button. The identifiers fill the output area, one per line, and are generated once automatically when the page opens. Click the output area to copy the whole batch. Each identifier is 26 uppercase characters: the first 10 encode the timestamp, the remaining 16 are random.
Step-by-Step Usage Guide
- Set the count of ULIDs you need, up to 100 per batch.
- Press the generate button; a fresh batch appears immediately.
- Click the output area to copy all identifiers at once.
- Store them in order; lexicographic sort equals time sort.
Technical Specifications & Standards
A ULID per the canonical specification is 128 bits: a 48-bit Unix-epoch millisecond timestamp followed by 80 bits of randomness, encoded as 26 Crockford Base32 characters. Crockford's alphabet drops I, L, O, and U to prevent transcription mistakes, which this generator follows with its 32-symbol set. The timestamp half is exact: the current Date.now value is encoded into the 10-character prefix, so identifiers from the same millisecond sort adjacently and any two ULIDs compare lexicographically in time order. The random half is where this implementation differs from the spec: it draws 10 random bytes and reuses them cyclically across the 16 random characters, taking only the low 5 bits of each byte, so the effective randomness is 50 bits rather than the specified 80. Identifiers remain unique for practical purposes in small batches, but for adversarial contexts or very large volumes use a library that implements the full 80 bits. There is also no monotonicity guarantee within a batch generated in the same millisecond; ties sort together without a defined order.
Targeted Use Cases
- Creating database primary keys that index well because they sort by creation time.
- Generating request or event ids whose order is visible without a separate timestamp column.
- Producing URL-safe ids for shared links, thanks to the unambiguous Base32 alphabet.
- Seeding test data with sortable identifiers across services.
Notes & Gotchas
- Use them where chronological sorting matters; the timestamp prefix makes ORDER BY id meaningful.
- Do not treat the random half as full-strength here; the generator uses fewer random bits than the spec's 80.
- Keep the uppercase form; decoding is case-insensitive in Crockford Base32, but consistency avoids confusion.
- Remember two ULIDs from the same millisecond share their prefix and have no guaranteed order between them.
Frequently Asked Questions
Why do ULIDs sort by time?
The first 10 characters encode the Unix millisecond timestamp in Crockford Base32, and the remaining characters are random. Lexicographic comparison therefore compares timestamps first, so sorting the string sorts by creation time.
Why are the letters I, L, O, and U missing?
They are deliberately excluded from Crockford's Base32 alphabet because they are easily confused with digits 1 and 0 or each other when identifiers are read aloud or transcribed.
Are these as random as a UUID v4?
The spec targets 48 timestamp bits plus 80 random bits, which is less randomness than UUID v4's 122 bits. This generator's random half carries fewer effective bits than that, so avoid it for adversarial unpredictability and use a spec-complete library there.
How many can I generate at once?
Up to 100 per batch. Generate additional batches freely; each batch uses the current millisecond for its timestamp prefix.