ULID Validator

ULID validation: time-sortable identifiers without the UUID v4 pain

A ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit identifier proposed by Alizain Feerasta in 2016 as a pragmatic alternative to UUID v4. The spec defines a fixed string form of 26 characters in Crockford Base32, encoding a 48-bit Unix-millisecond timestamp followed by 80 bits of randomness — a real example looks like 01H7XBJX2VJF8Z5TQXM9RTPDC0.

The Crockford alphabet is the key trick: it deliberately excludes the visually ambiguous letters I, L, O and U, so a ULID can be dictated by phone, printed on a receipt, or scanned by OCR without ambiguity. Structural validation reduces to a single case-insensitive regex:

/^[0-9A-HJKMNP-TV-Z]{26}$/i

Anatomy of the 26 characters

• Chars 1–10 — 48-bit timestamp, milliseconds since the Unix epoch. Good until the year 10889.
• Chars 11–26 — 80 bits of cryptographic randomness. That is 1.21 × 10²⁴ distinct values per millisecond.
• Because timestamp comes first and the alphabet is ordered, lexicographic sort matches chronological order. ORDER BY id is the same as ORDER BY created_at — no extra column needed.
• The spec also defines a monotonic mode: if two ULIDs are generated in the same millisecond, the random portion of the second is incremented from the first, guaranteeing strict ordering with zero collisions.

ULID vs UUID v4 vs UUID v7

ULID vs UUID v4: v4 is 122 bits of pure randomness — unsortable, which causes B-tree index fragmentation in Postgres and MySQL. ULID solves this by putting time first. ULID is also shorter as a string (26 vs 36 chars) and has no hyphens.

ULID vs UUID v7 (RFC 9562, 2024): both encode a millisecond timestamp + randomness in 128 bits, but v7 is now an IETF standard while ULID is a community spec. UUID v7 reuses the standard 8-4-4-4-12 hex form (36 chars); ULID uses Crockford Base32 (26 chars, no ambiguous letters). For new greenfield projects, UUID v7 is the safer choice for interoperability; ULID remains popular where the shorter string and human-friendly alphabet matter.

Storage, libraries and gotchas

In Postgres you typically store ULIDs as CHAR(26) or VARCHAR(26), sometimes as BYTEA(16) for compactness. Validation libraries in the wild: ulid on npm (by Eric Vallabh Minikel), python-ulid, ulid-rs in Rust. The default casing is uppercase, but most parsers accept lowercase as well — case-insensitive comparison is the safest. The biggest operational gotcha is clock drift: if a server's clock jumps backwards, newly generated ULIDs will sort before older ones, breaking the time-ordered guarantee. Keep your NTP healthy.

Where ULID shines

• Distributed primary keys — generate IDs on any node without coordination, still get index-friendly inserts.
• Event sourcing — events sort naturally by time, no separate sequence required.
• Log correlation IDs — copy-paste-friendly in a terminal, no ambiguous chars.
• IndexedDB keys — sortable cursor traversal in the browser.

FAQ

Should ULID replace UUID in my new project? Yes if you index by ID and need time-ordering and your stack already has a ULID library. Otherwise pick UUID v7 — it gives you the same sortability with a standardized format.

Is ULID case-sensitive? No. The canonical output is uppercase, but Crockford Base32 is case-insensitive on input; 01h7xbjx2vjf8z5tqxm9rtpdc0 decodes to the same bytes as the uppercase form.

How big is the collision risk? 80 bits of randomness per millisecond. To get a 50% collision probability in the same millisecond by birthday bound you would need around 1.2 billion ULIDs in that one millisecond — practically impossible. Across milliseconds, the timestamp prefix guarantees uniqueness.

Does the timestamp leak information? Yes — anyone reading a ULID can decode the millisecond of creation. If you publish IDs to untrusted users and need privacy of creation time, prefer UUID v4 or hash the ULID.