What a ULID is
A ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit value — the same size as a UUID — split into a 48-bit millisecond timestamp and 80 bits of randomness, then encoded as a 26-character string. Unlike a random UUID, a ULID sorts chronologically as plain text: because the timestamp occupies the leading characters and the encoding alphabet preserves numeric order, comparing two ULIDs as strings gives the same answer as comparing the 128-bit values they represent. No coordinator or machine ID is required to generate one — see the official ULID spec for the full reference.
The layout
chars 0-9 (10 chars) chars 10-25 (16 chars)
timestamp, ms since Unix epoch randomness
48 bits (encoded in 50) 80 bits
01ARZ3NDEK TSV4RRFFQ69G5FAV
- 48-bit timestamp — plain milliseconds since the Unix epoch (not a custom epoch like Snowflake IDs use). That's enough range to reach the year 10889 before it wraps.
- 80-bit randomness — generated fresh for each ULID using a cryptographically secure random source, giving roughly 1.21 × 10²⁴ possible values per millisecond before a collision becomes a realistic concern.
- Crockford's Base32 encoding — 32 symbols (
0-9andA-ZminusI,L,O, andU, dropped to avoid confusing them with1,1,0, and to sidestep spelling accidental words) mapped in an order that matches plain ASCII order. That's what makes string comparison and numeric comparison agree.
Monotonic ULIDs
Millisecond resolution means two ULIDs generated in the same tick get independent random suffixes by default — nothing guarantees the second one sorts after the first. The standard fix, used by most ULID libraries, is monotonic mode: when a new ULID is requested in the same millisecond as the last one, increment the previous random value by 1 instead of drawing a fresh one. That keeps strict ordering within a millisecond at the cost of making the random part of back-to-back IDs predictable — worth knowing if an attacker could ever see one ULID and needs to guess the next.
Toggle Monotonic off below and click Generate 5 rapidly to see IDs generated in the same millisecond come out in a random order instead of generation order — then turn it back on to see the difference.
ULID vs UUID vs Snowflake ID
A UUID v4 is 128 bits of pure randomness: no coordination needed and no information leaked, but it doesn't sort by creation time and makes a poor database index key since inserts land at random points in the index. A Snowflake ID is smaller (64 bits) and also sorts chronologically, but needs a coordinated machine ID to avoid collisions across multiple generators. A ULID sits between the two: it sorts chronologically like a Snowflake ID, needs no machine coordination like a UUID, and its extra size (128 vs 64 bits) buys enough randomness that two independent processes can generate IDs without ever agreeing on who they are.
What this tool does
Generate mode mints ULIDs entirely in your browser using the Web Crypto API for randomness — nothing is sent anywhere, so generated IDs are for testing and demonstration, not a guarantee of production-grade uniqueness tracking. Decode mode reverses the process — paste in any 26-character ULID to recover its embedded timestamp and see its random component in hex.
FAQ
Are ULIDs case-sensitive?
No — Crockford's Base32 is case-insensitive by design. This tool normalizes input to uppercase before decoding, and the canonical form most libraries produce is uppercase.
Can a ULID be converted to/from a UUID?
Yes — both are 128-bit values, so a ULID's underlying bits can be formatted as a standard UUID string (with hyphens) and vice versa. The only thing that changes is the text representation; the bits mean the same thing either way.
Is anything I enter here sent anywhere?
No — generation and decoding both run entirely in your browser. Nothing is ever sent to a server.