ULID Generator

A ULID (Universally Unique Lexicographically Sortable Identifier) solves a specific problem that UUID v4 does not: it needs to be both globally unique and sortable in the order it was created. A standard UUID v4 is almost entirely random, which is great for uniqueness but means a batch of UUIDs generated over time gives you no way to tell which came first without a separate "created_at" column. A ULID bakes a millisecond-precision timestamp directly into the front of the identifier, so sorting a list of ULIDs as plain text automatically sorts them by creation time — no extra column, no extra index, no extra query. This matters more than it might first seem for database performance. Many databases store rows physically ordered (or indexed) by their primary key. If that key is a random UUID, every insert lands at a random point in the index, causing page splits and fragmentation that get worse as the table grows — a well-documented pain point for UUID-keyed tables at scale. A ULID primary key, being roughly time-ordered, inserts close to the end of the index most of the time, behaving much more like a traditional auto-incrementing integer while still being safe to generate on multiple machines independently without coordination. This is why ULIDs (and similar time-sortable ID schemes like Twitter's Snowflake or Stripe's newer object IDs) have become popular for high-throughput systems that still want the distributed-generation benefits UUIDs offer. A ULID is 26 characters long, encoded in Crockford's base32 — a variant of base32 that deliberately excludes the letters I, L, O and U. Those four are dropped because they are easy to confuse with other characters when read or typed by hand: I and L can look like the digit 1, O can look like the digit 0, and U was additionally excluded to avoid accidentally spelling profanity when random characters happen to line up. The remaining 32-character alphabet (0-9 and A-Z minus I, L, O, U) means every character unambiguously represents one of 32 values, and the encoding is also case-insensitive-safe by convention (though this tool defaults to uppercase, matching the ULID specification, with a lowercase option available). The first 10 characters encode a 48-bit millisecond timestamp — enough range to represent dates far beyond the year 10889, so it will not run out any time soon. The remaining 16 characters encode 80 bits of randomness generated fresh for every ID with `crypto.getRandomValues()`, the same cryptographically secure randomness source used elsewhere in this tools category. Two ULIDs generated in the same millisecond will still differ (and be effectively impossible to guess) because of that randomness — only their sort order becomes ambiguous relative to each other within that single millisecond, which is rarely a practical problem.