ULID Decoder
Decode a ULID to extract its embedded Unix timestamp and random component. ULIDs are Crockford Base32-encoded, sortable, and compatible with UUID.
ULID
ULID Structure
The ULID decoder takes a 26-character ULID and extracts its embedded Unix timestamp (in milliseconds) and 80-bit randomness component. ULIDs are designed to be lexicographically sortable, case-insensitive, and compatible with UUID storage, which makes them increasingly popular as a replacement for UUID v4 in modern databases and APIs.
What a ULID Actually Is
ULID stands for Universally Unique Lexicographically Sortable Identifier. It is a 128-bit value encoded as 26 characters of Crockford Base32 (the alphabet 0-9 and A-Z minus I, L, O, U to avoid visual confusion). The value packs two pieces of information:
- Timestamp (48 bits, first 10 characters): the Unix time in milliseconds at the moment the ULID was generated. 48 bits is enough to represent dates up to the year 10889, so overflow is not a concern.
- Randomness (80 bits, last 16 characters): a cryptographically random value that guarantees uniqueness even when multiple ULIDs are generated in the same millisecond. The randomness is large enough that collisions are virtually impossible (2^80 possibilities per millisecond).
The Crockford Base32 alphabet was chosen for human-friendliness: the letters I, L, and O are excluded because they look like 1 and 0. The decoder is lenient and accepts these letters as if they were the digits they resemble (case-insensitive), matching the official ULID spec's recommendation for input handling.
How the Decoder Works
Paste a 26-character ULID into the input. The decoder parses the first 10 characters as the timestamp and the remaining 16 as the randomness, then reports both as separate values. The timestamp is shown in milliseconds, seconds, full readable date (your local timezone), ISO 8601, and relative description ("3 months ago", "in 2 days").
- Validation: the decoder rejects inputs that are not exactly 26 characters, contain characters outside the Crockford alphabet, or start with a character greater than 7 (the first character can only be 0-7 because the timestamp is 48 bits and the leading 5-bit nibble has limited range).
- UUID compatibility: the decoder also outputs the same 128-bit value formatted as a UUID (8-4-4-4-12 hex with dashes). This is useful for storing ULIDs in databases that have a native UUID column type but not a ULID type.
- Randomness display: the 80-bit random value is shown as a hex string for inspection. Two ULIDs with the same timestamp but different randomness were generated in the same millisecond by different processes.
For other timestamp-bearing identifiers, see the UUID decoder (v1, v6, v7 all embed timestamps), the MongoDB ObjectId decoder, or the Snowflake decoder (Discord, Twitter, Instagram). For decoding an authentication token instead, the JWT decoder handles JSON Web Tokens.
Why ULIDs Are Used Instead of UUID v4
UUID v4 is the most common identifier format because every standard library can generate it, but it has two practical drawbacks: it is not sortable by creation time, and the dashed hex format is verbose. ULIDs fix both:
- Lexicographic sortability: sorting ULIDs as strings automatically sorts them by creation time because the timestamp is in the high bits and Base32 encoding preserves the order. This makes ULIDs work well as primary keys in databases that paginate by ID order.
- Compact representation: 26 characters with no dashes, versus 36 characters with dashes for UUID. The display is shorter in logs, URLs, and copy-paste contexts.
- Case-insensitive Crockford alphabet: users can type ULIDs in any case and the result is the same. The alphabet also excludes letters that look like digits, reducing transcription errors.
- UUID-compatible storage: the underlying 128 bits are identical to a UUID's, so a ULID can be stored in a UUID column with no schema change.
UUID v7 (added in RFC 9562 in 2024) provides similar properties to ULIDs while staying within the UUID format. For a comparison, see the UUID decoder, which handles both. To generate new ULIDs or UUIDs, use the UUID / ULID generator.
Monotonicity and Same-Millisecond Generation
The ULID specification includes an optional "monotonic" mode that guarantees IDs generated in the same millisecond are strictly increasing. In monotonic mode, when two ULIDs share the same timestamp, the second one's randomness is the first one's randomness plus one (with carry into the next byte). This preserves sort order across very fast burst generation.
Non-monotonic generators (the default in most libraries) pick a new random value for each ULID, which means ULIDs in the same millisecond may not be strictly ordered. For most use cases this does not matter because the millisecond resolution is already finer than human-perceivable events. If your application requires strict ordering even within a single millisecond, enable monotonic mode in your ULID library.
Frequently Asked Questions
A ULID is a 128-bit identifier encoded as 26 characters of Crockford Base32. The first 10 characters hold a 48-bit millisecond timestamp; the last 16 hold 80 bits of randomness. ULIDs sort by creation time when compared as strings, which makes them a popular replacement for UUID v4 as a database primary key. The format was published in 2016 by Alizain Feerasta on GitHub.
Paste the 26-character ULID into the decoder. The Full Date and Time row in the result shows the exact moment the ULID was created, accurate to the millisecond. The decoder also reports the timestamp as a Unix integer in both seconds and milliseconds, plus an ISO 8601 string, so you can copy whichever format your application needs.
The Crockford Base32 alphabet excludes the letters I, L, O (because they look like 1, 1, and 0) and U (to avoid spelling certain words by accident). The remaining 32 characters (0-9 and A-Z minus those four) encode 5 bits each, which is exactly what Base32 needs. Skipping the visually-ambiguous letters reduces transcription errors when humans read or copy a ULID.
No. ULIDs are case-insensitive: 01ARZ3NDEKTSV4RRFFQ69G5FAV and 01arz3ndektsv4rrffq69g5fav are the same value. The canonical representation is uppercase, but parsers should accept either. The decoder normalizes to uppercase internally before parsing.
Yes. ULIDs sort lexicographically by creation time when compared as 26-character strings, because the timestamp occupies the high-order positions and Crockford Base32 preserves numeric order. This is the main reason teams pick ULIDs over UUID v4: a chronologically-sortable ID makes database pagination, log analysis, and time-window queries simpler without an extra index.
Yes. A ULID is 128 bits, exactly the same size as a UUID. The decoder shows the UUID-compatible representation (in the standard 8-4-4-4-12 dashed hex format) so you can insert it into a Postgres UUID column or any database with native UUID support. You convert back and forth by re-encoding the 128 bits between Base32 (ULID display) and hex (UUID display).
Both put a millisecond Unix timestamp in the high bits followed by randomness. UUID v7 (RFC 9562, 2024) uses the standard UUID 8-4-4-4-12 hex layout, while ULID (2016) uses 26-character Crockford Base32. The two formats represent the same kind of data; the choice is mostly aesthetic and ecosystem-driven. UUID v7 is a better fit for systems already using UUIDs; ULID is shorter and more human-readable.
The 48-bit timestamp field can hold dates up to August 2, 10889. After that the timestamp overflows. There is no practical concern about ULID exhaustion within any realistic horizon. Compare this to Snowflake (overflows in 2080s) or 32-bit Unix timestamps (overflow in 2038).
The 80-bit randomness section is large enough that guessing is computationally infeasible (2^80 = ~10^24 possibilities per millisecond). However, the timestamp section is fully predictable, which means an attacker who knows roughly when a ULID was generated can narrow the search space significantly. Treat ULIDs as identifiers, not as secrets. For session tokens or password-reset links, use a true random token instead.
Monotonic mode is an optional generation strategy that guarantees ULIDs created in the same millisecond are strictly increasing. The second ULID's randomness is the first one's plus one, instead of a fresh random value. This preserves sort order for burst generation but slightly reduces the entropy of consecutive IDs. Most libraries default to non-monotonic; enable monotonic only if you need strict sub-millisecond ordering.