Crockford-base32 de 26 de caractere, sortabile lexicografic după timestamp-ul în milisecunde. Generate local - nu se transmite niciodată.
(Documentație în engleză)
What it does
Generates ULIDs: 26-character identifiers that pair a millisecond timestamp with 80 bits of randomness. The tool fills itself in the moment it loads and re-rolls on every option change, so there is always a result on screen. Set Count from 1 to 1,000. A single value renders in large type; a batch renders as a list. Copy takes the whole batch. Everything runs locally with crypto.getRandomValues.
How to use it
- Set Count (1 to 1,000). Results regenerate as you change it.
- Read the result: one value in large type, two or more as a list.
- Press Copy to take the whole batch.
- Paste any
ULIDULIDA 128-bit identifier like a UUID, but timestamp-prefixed and Crockford-base32 encoded — so it sorts by creation time and is shorter to read.
into Decode aULIDULIDA 128-bit identifier like a UUID, but timestamp-prefixed and Crockford-base32 encoded — so it sorts by creation time and is shorter to read.
to inspect it: the tool splits time part from randomness and shows the timestamp in milliseconds and ISO-8601 UTC. Invalid input (wrong length, non-Crockford character, or a time part past the 48-bit ceiling) shows the exact reason.
Examples
A
ULIDULIDA 128-bit identifier like a UUID, but timestamp-prefixed and Crockford-base32 encoded — so it sorts by creation time and is shorter to read.
is 26 characters. The split is the whole point:01ARZ3NDEKTSV4RRFFQ69G5FAV
└──┬──┘└───────┬────────┘
timestamp randomness
(10 chars) (16 chars)
01ARZ3NDEKTSV4RRFFQ69G5FAV- the spec’s canonical example01ARZ3NDEK...sorts before01ARZ3NDF...because 10 characters of timestamp lead the string- Pasting
01ARZ3NDEKTSV4RRFFQ69G5FAVinto the decoder reads the timestamp2016-07-30T23:54:10.259Z— the spec’s canonical example was minted on 2016-07-30
How ULIDs work
A
ULIDULIDA 128-bit identifier like a UUID, but timestamp-prefixed and Crockford-base32 encoded — so it sorts by creation time and is shorter to read.
is 128 bits, cut in two:| Part | Bits | Characters | Holds |
|---|---|---|---|
| Timestamp | 48 | first 10 | milliseconds since the Unix epoch |
| Randomness | 80 | last 16 | random bits |
Both halves encode in Crockford base32: 32 symbols, 5 bits per character. The alphabet is 0-9 then A-Z minus I, L, O, U. That makes ULIDs case-insensitive and removes the letters people misread (I as 1, O as 0). 26 characters times 5 bits is 130, so the top 2 bits sit unused.
The timestamp is what you are buying. It occupies the most significant end of the value, so string order equals creation order: sort a column of ULIDs as plain text and you get insertion order for free. Compare with UUIDv4:
| Property | ULIDULIDA 128-bit identifier like a UUID, but timestamp-prefixed and Crockford-base32 encoded — so it sorts by creation time and is shorter to read. |
UUIDv4 |
|---|---|---|
| Characters | 26 | 36 (with 4 hyphens) |
| Sorts by creation time | yes, lexicographic | no - fully random order |
| Random bits | 80 | 122 |
UUIDv4 is fine when identifiers only need to be unique. When they also need to sort - database keys, event logs, anything you page through - the timestamp prefix turns an index scan into a range read. The 48-bit millisecond clock reaches the year 10889, so it will not overflow in practice.
Same millisecond, different ULIDs: the 80 random bits keep same-instant IDs distinct with a collision chance so small it is ignored at normal volumes.
Good to know
- Sortable, not ordered. ULIDs sort by millisecond; two IDs inside one millisecond have no guaranteed order.
- Case-insensitive.
01arz3ndektsv4rrffq69g5favparses as the same value as the uppercase form. - Private: generated locally in your browser. Nothing is sent anywhere.
- Related tools:
UUIDUUIDA 128-bit identifier generated to be practically unique without coordination, most commonly in version-4 (fully random) form.
Generator, Token Generator.