ULID Decoder

There are four common causes and the decoder distinguishes between them. The first is length: a ULID is exactly 26 characters, so a 25 or 27 character string has been truncated or has picked up a stray character, and a 36 character string with hyphens is a UUID rather than a ULID. The second is the alphabet: Crockford Base32 deliberately omits I, L, O, and U, so a string containing any of those has either been mistyped or has been produced by something that is not a ULID encoder. Conforming decoders map I and L to 1 and O to 0 when reading, since those substitutions come from human transcription, but a U is unambiguously wrong. The third is overflow: the first character encodes only the top bits of the 48-bit timestamp, so it cannot exceed 7, and a ULID starting with 8 or higher describes a timestamp beyond the representable range. The fourth is invisible characters, usually a zero-width space or a non-breaking space picked up when copying from a web page or a chat client, which makes a visually correct ULID fail a length check.

Not by default, and this is the most common misunderstanding about the format. The base specification fills the random component with 80 fresh random bits on every call, so two ULIDs generated in the same millisecond share an identical timestamp prefix and are then ordered by whatever their random tails happen to be, which is effectively arbitrary. For most uses that is acceptable, since ordering within a millisecond rarely carries meaning. When it does matter, the specification describes an optional monotonic generator: within the same millisecond it takes the previous random value and increments it by one instead of drawing a new one, which guarantees that later calls sort after earlier ones. Most mature ULID libraries expose this as a separate monotonic factory rather than the default, so you have to opt in. Be aware that a monotonic generator holds state, meaning two processes generating ULIDs concurrently are monotonic only within themselves, and that the increment can overflow if a single process generates more than 2^80 IDs in one millisecond, which is not a realistic concern.

Yes, because both are 128-bit values and the conversion is a pure re-encoding of the same bits. Decode the 26 Crockford Base32 characters into 16 bytes and print those bytes as hexadecimal in the 8-4-4-4-12 grouping, and you have a UUID-shaped string that round-trips back to the original ULID. This is a common storage strategy: keep the value in a native UUID column so the database gets a compact 16-byte binary key with full index support, and present it as a ULID at the API boundary where the shorter URL-safe text is nicer. The caveat is that the result is not a valid UUID of any version. The bits that a UUID reader expects to find in the version and variant fields are, in a ULID, ordinary timestamp and randomness bits, so a strict UUID parser will report a nonsensical version and an unexpected variant. That is harmless as long as nothing downstream tries to interpret the value as a versioned UUID, but it means you cannot mix converted ULIDs and real UUIDs in a column where consumers branch on the version digit.