// generate sortable, timestamp-embedded unique identifiers
Generate ULIDs (Universally Unique Lexicographically Sortable Identifiers) instantly. Bulk generation, decode timestamp from any ULID, convert to/from UUID. Browser-based, free, no signup.
Click Generate to create ULIDs
Configure options and quantity on the leftSet the quantity using the slider or presets (up to 10,000). Toggle monotonic mode for guaranteed sort order within the same millisecond. Click "Generate" or "↺ Regen" to refresh.
Paste any ULID into the Decode section to extract the embedded timestamp (to the millisecond), the randomness portion, and see the UUID representation.
Convert any ULID to its UUID equivalent, or convert any UUID v4/v7 back to a ULID. Both directions are supported with one-click copy.
ULIDs sort chronologically by default — no need for a separate created_at column for ordering. They use Crockford Base32 encoding (no ambiguous characters like I, L, O, U), making them URL-safe, readable, and case-insensitive. They also avoid the database index fragmentation problem of random UUID v4.
A ULID is a 128-bit unique identifier encoded as 26 Crockford Base32 characters. The first 10 characters encode the current Unix timestamp in milliseconds (48 bits). The remaining 16 characters encode 80 bits of cryptographically random data. The result is universally unique, lexicographically sortable, and interchangeable with UUID in any 128-bit ID column.
Crockford Base32 is a base-32 encoding scheme that uses 32 characters chosen to be unambiguous: 0123456789ABCDEFGHJKMNPQRSTVWXYZ. The characters I, L, O, and U are excluded to avoid confusion with 1, 1, 0, and the letter V. It is case-insensitive and contains no special characters, making it URL-safe without percent-encoding.
Within a single millisecond, multiple ULIDs might be generated with different random portions. Without monotonic mode, these ULIDs would not have a guaranteed order. In monotonic mode, when multiple ULIDs are generated in the same millisecond, the random portion of each subsequent ULID is incremented by 1 from the previous. This guarantees that even within the same millisecond, ULIDs sort in generation order.
Yes. A ULID is 128 bits — the same size as a UUID. Most databases that support UUID columns (PostgreSQL, MySQL, SQL Server) can store ULIDs directly, either as a UUID type (after converting to UUID format) or as a CHAR(26). The Convert section in this tool converts between ULID and UUID formats for exactly this purpose.
Both ULID and UUID v7 embed a Unix millisecond timestamp for lexicographic sortability. The main differences: ULID uses Crockford Base32 encoding (26 chars, URL-safe, no hyphens), while UUID v7 uses the standard hex + hyphen format (36 chars). UUID v7 is an official IETF RFC (RFC 9562), while ULID is a community specification. For new projects, either works well; choose based on ecosystem support and personal preference.
Without monotonic mode, an unlimited number of unique ULIDs can be generated per millisecond — collisions are prevented by the 80 bits of randomness (2^80 ≈ 1.2 × 10^24 possibilities). In monotonic mode, the randomness is incremented rather than randomised, which allows up to 2^80 ULIDs per millisecond before overflow. In practice, you will never approach this limit.
Yes. All random bits are generated using crypto.getRandomValues() — the browser's CSPRNG. The timestamp portion is derived from Date.now(). In monotonic mode, the first ULID per millisecond uses a random seed, and subsequent ones increment that seed — both the seed and all other random bits come from the CSPRNG.
The Universally Unique Lexicographically Sortable Identifier was designed to solve a specific pain point with UUID v4: it's random, so it can't be sorted by creation time without a separate timestamp column, and its randomness fragments database B-tree indexes on insertion. ULIDs fix both problems by embedding the current millisecond timestamp in the first 10 characters.
UUID uses hexadecimal (16 characters) with hyphens added for readability, resulting in 36-character strings. ULID uses Crockford Base32 (32 characters), which is more efficient — 26 characters fit the same 128 bits. The encoding excludes I, L, O, U to prevent confusion with 1, 1, 0, and V. It contains no special characters — no hyphens, no slashes — making it natively URL-safe.
A key advantage of ULIDs and UUID v7 over UUID v4 for database primary keys is index locality. When rows are inserted with sequential IDs, each new row appends to the end of the B-tree index, which is efficient. Random UUIDs land in random index locations, causing frequent page splits and cache misses. In high-insert-rate databases, this can measurably degrade write throughput. ULIDs, like UUID v7, behave more like sequential integers from the index's perspective while maintaining global uniqueness.