ULID Generator

ULID Generation Options
Generated ULIDs
ULID Decoder & Validator
About ULID

ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit identifier with millisecond precision timestamps and lexicographic sorting capability.

ULID Structure

ULID format (26 characters):

01AN4Z07BY79KA1307SR9X4MV3
  • Timestamp: 48-bit (10 chars)
  • Randomness: 80-bit (16 chars)
  • Encoding: Crockford Base32
  • Case insensitive, URL-safe
ULID Advantages
  • 📅 Chronologically Sortable
  • 🔗 URL-Safe Characters
  • 🎯 Case Insensitive
  • No Special Characters
  • 🔄 Monotonic Sort Order
Common Use Cases
  • 🗄️ Database Records
  • 📊 Event Sourcing
  • 📋 Log Entries
  • 🔗 API Resources
  • 📱 Mobile Apps
Quick Actions

Why ULIDs Sort and Random UUIDs Don't

A ULID packs a 48-bit millisecond timestamp and 80 random bits into 26 Crockford Base32 characters. Because the timestamp comes first, plain string comparison sorts ULIDs chronologically - which is exactly what a B-tree index wants. Random UUID v4 keys land in random index positions and fragment the tree; time-ordered IDs simply append. The index benchmarks and byte-level structure are covered in UUID vs ULID.

The trade-off: anyone holding a ULID can decode when it was created - paste one into the decoder above to see for yourself. If you need time-ordering but your stack speaks UUID, UUID v7 gives you the same property in standard UUID clothing. For shorter, URL-safe IDs there is also Nanoid - the three formats are compared head-to-head in Nanoid vs UUID vs ULID.

ULID Questions

Both are 128-bit unique IDs. The key difference is that ULIDs sort lexicographically by time - newer IDs come after older ones. They're also shorter (26 chars vs 36) and use Base32 instead of hex. Handy when you want IDs that naturally order by creation time.

When ordering matters. Event logs, audit trails, database records where you'd otherwise need a "created_at" column for sorting. ULIDs give you that for free. They're also nicer in URLs - no hyphens, case-insensitive.

Yes, they're both 128 bits. Most ORMs can convert between them. Just know that you'll lose the sorting benefit once it's stored as a UUID - the byte ordering is different.

Millisecond precision. The timestamp covers dates from 1970 through roughly the year 10889, so you're set for a while.