ULID decoder

The Randogram ULID decoder takes an identifier apart: it shows the creation time, the random part and the same value in other forms.

Decoding happens right in the browser: the identifier is never sent anywhere. A ULID holds 128 bits written in 26 characters of the Crockford Base32 alphabet. The first 10 characters are 48 bits of Unix time in milliseconds, so the moment of creation can be read out of any ULID. The last 16 characters are 80 random bits, and nothing can be recovered from them. Besides the time, the decoder shows the same 128 bits in hexadecimal and in UUID form — that is usually how the identifier sits in a database column.

Questions and answers

What can be learned from a ULID?

The creation time. The first 10 characters out of 26 are 48 bits of Unix time in milliseconds, so the moment of creation can be read out of any ULID without any keys. The other 16 characters are 80 random bits, and nothing can be recovered from them. If disclosing the creation time is undesirable, take an identifier without a timestamp — a NanoID or a version 4 UUID.

Is the identifier sent to the server?

No. Decoding runs in the browser in JavaScript: the pasted value never leaves your machine, never reaches the server logs and is not stored anywhere. For the same reason the decoder keeps working without a connection once the page is open.

Why is a ULID also shown in UUID form?

Because that is usually how it sits in a database: both a ULID and a UUID are 128 bits, and ULIDs are often kept in a uuid column so as not to spend the space on a string. By the standard such a value is not a UUID — it carries no version or variant field — but this is the form you need in order to find the row.