ULID Generator and Decoder | Mint and Read Time-Sortable IDs

Generate a 26-character Crockford Base32 ULID with one click, or paste one to pull out its embedded creation time. The first 10 characters carry a 48-bit millisecond timestamp and the final 16 carry 80 bits of randomness, so the decoded panel shows the millisecond value, the ISO 8601 UTC date, the random tail in hex, and whether the string is well-formed.

💡 About this tool

ULIDs look like opaque 26-character blobs, but half of that string is a readable timestamp hiding in plain sight. The trouble is that the timestamp is Crockford Base32, not hex or decimal, so you cannot just glance at 01ARZ3NDEKTSV4RRFFQ69G5FAV and know when it was created. Decoding it by hand means mapping each of the first ten characters back to a 5-bit value, accumulating them in base 32, and converting the result to a date.

This tool does that round trip both ways. Paste a ULID and it validates the length, rejects any character outside the Crockford alphabet (which deliberately omits I, L, O and U to dodge visual mix-ups), splits the timestamp from the random tail, and renders the creation time as an ISO 8601 string. The segment view paints the time half and the random half in different colours so the structure is obvious at a glance, which is the part you cannot get from a one-line library call.

🧐 Frequently Asked Questions

How is a ULID different from a UUID v4? A UUID v4 is 122 bits of pure randomness with no inherent order. A ULID front-loads a 48-bit millisecond timestamp, so two ULIDs minted at different times sort into chronological order by plain string comparison. UUID v7 added a similar timestamp prefix later; ULID has carried one since its 2016 spec.

Why does lexicographic order match time order? Because the most significant bits come first. The timestamp occupies the leading 10 characters, so when you sort ULID strings alphabetically the older ones naturally come first. That makes ULIDs convenient as database primary keys, where ordered inserts keep B-tree indexes tightly packed.

What is Crockford Base32? It is a base-32 alphabet that drops the letters I, L, O and U. I and L are excluded to avoid confusion with 1, O to avoid confusion with 0, and U to avoid accidental profanity. That leaves 0-9 and the remaining 22 uppercase letters, 32 symbols total, each encoding 5 bits.

Can two ULIDs collide? Within the same millisecond, collision depends on the 80 random bits, which give roughly 1.2 x 10^24 possibilities. A practical clash is astronomically unlikely. The randomness here comes from the browser's crypto.getRandomValues, not a weak pseudo-random source.

Does the tool care about upper versus lower case? No. The Crockford encoding is case-insensitive on decode, so the input is normalised to uppercase before validation. You can paste a lowercase ULID and still get a clean decode.

📚 The Story Behind the 26th Character

ULID was published by Alizain Feerasta in 2016 as a reaction to UUID v4 being a poor fit for sorted databases, and the format has a couple of deliberate quirks worth knowing. The timestamp field is 48 bits, which covers dates up to the year 10889 before it overflows, so it is not a problem you will personally encounter. The encoding pads the value to exactly 26 Crockford characters: 48 timestamp bits and 80 random bits make 128 total, the same width as a UUID, which is no accident. It was designed to fit the same 128-bit storage column. The reason it lands on 26 characters rather than the 25 you might expect from 128 bits divided by 5 is that the leading character only uses 3 of its 5 bits, which is also why a valid ULID never starts with a character above 7.