ULID Generator
Generate sortable, URL-safe ULIDs in bulk — a 48-bit timestamp plus 80 bits of randomness
crypto.getRandomValues and never leaves your browser.About this tool
The ToolNinja ULID Generator creates ULIDs (Universally Unique Lexicographically Sortable Identifiers) in bulk — a 26-character identifier combining a 48-bit millisecond timestamp with 80 bits of randomness, encoded in Crockford's Base32 alphabet (which skips the visually ambiguous I, L, O, and U). The timestamp-first design is the whole point: because the first 10 characters encode time, ULIDs generated later always sort after ones generated earlier when compared as plain strings — the same database-index-friendly property UUID v7 offers, but in a shorter, case-insensitive, URL-safe alphabet with no hyphens. Where a classic random UUID v4 forces a database to insert into random positions in a B-tree index (causing page splits and index fragmentation at scale), both ULID and UUID v7 insert roughly in order, which is measurably cheaper for write-heavy tables. Everything runs 100% in your browser via crypto.getRandomValues — no ID is ever sent anywhere.
When to use it
- →Generating database primary keys that sort chronologically and insert efficiently into a B-tree index
- →Creating sortable identifiers for a distributed system where multiple nodes generate IDs independently
- →Producing test fixture IDs that are both unique and meaningfully ordered by creation time
- →Migrating a schema from UUID v4 to a sortable ID format and generating sample values to test with
Tips
- ◆The first 10 characters (highlighted) encode the timestamp — sorting ULIDs as plain strings sorts them chronologically, with no separate created_at column needed for basic ordering.
- ◆Crockford Base32 deliberately excludes I, L, O, and U to avoid confusion with 1, 1, 0, and V — safe to read aloud or transcribe by hand, unlike a UUID's hex-and-hyphens.
- ◆Set a custom timestamp to generate a ULID as if it were created at a specific point in time — useful for backfilling or testing time-based sorting logic.
Frequently asked questions
What's the actual difference between a ULID and a UUID v7?
Both encode a millisecond timestamp first, specifically so IDs sort chronologically — that part is functionally equivalent. The difference is encoding: ULID uses 26 characters of Crockford Base32 with no separators, while UUID v7 uses the traditional 36-character hyphenated hex format. ULID is shorter and avoids hyphens, which matters if you're embedding IDs in URLs or file names; UUID v7 has the advantage of fitting directly into existing UUID-typed database columns without a schema change.
Why does ID sort order matter for a database primary key?
A B-tree index (what most databases use for primary keys) stays efficient when new entries insert near the end, appending to the rightmost page. A fully random key like UUID v4 inserts into random positions throughout the tree instead, causing page splits and fragmentation that measurably slows down writes and bloats the index at scale — a well-documented problem specifically motivating the move to sortable ID formats like ULID and UUID v7.
Can two ULIDs generated in the same millisecond collide?
In theory, yes — if both share the millisecond timestamp, uniqueness depends entirely on the 80 bits of randomness, same as any sufficiently-random identifier. In practice, the collision probability within the same millisecond is astronomically small (comparable to UUID v4's own collision odds), which is why ULID doesn't bother with a dedicated monotonic counter for most use cases — only an implementation that specifically needs guaranteed strict ordering within the same millisecond adds one.