UUID & ULID Generator,
bulk IDs with timestamp decoding.

ID formats guide

UUID, ULID, and when to use each.

Why unique identifiers matter

Distributed systems — microservices, multi-tenant databases, event-driven architectures — need to generate unique IDs without a central authority. Sequential integer IDs require a central counter; UUIDs and ULIDs solve this by using random bits or timestamp-seeded entropy that makes collisions astronomically unlikely without any coordination.

UUID v4: the reliable workhorse

UUID v4 is the most widely-used format for general-purpose unique IDs. It is 128 bits of near-randomness (122 random bits; 6 bits encode version and variant). The collision probability for 1 billion UUID v4s generated per second for 100 years is roughly 50% — meaning you would need to generate quadrillions of IDs before a collision becomes likely.

The main limitation: UUID v4s do not sort by time. If you store millions of UUIDs as a database primary key, the random order causes scattered B-tree page writes, fragmenting the index and degrading write performance at scale.

ULID: time-sortable by design

ULID fixes UUID v4's sorting problem by prepending a 48-bit millisecond timestamp to the 80 bits of randomness. ULIDs generated within the same millisecond are ordered by their random suffix; ULIDs generated in different milliseconds sort in chronological order.

Practical implications for databases: clustered inserts into UUID primary key columns cause page splits and index fragmentation. ULID primary keys behave like monotonically increasing sequences — rows inserted chronologically write to the end of the B-tree index, dramatically improving insert throughput at high write volumes.

UUID v1: time-based UUIDs

UUID v1 also embeds a timestamp, but stores it in a fragmented, big-endian format that makes lexicographic sorting unreliable. It also encodes the MAC address of the generating machine, creating a privacy concern in shared or containerized environments. For new projects, ULID is generally preferred over UUID v1 for time-sortable IDs.

The Crockford Base32 advantage

ULID uses Crockford Base32 rather than hexadecimal for its string representation. This produces shorter strings (26 chars vs 36 for UUID with hyphens), eliminates visually ambiguous characters (I/L/O/U), and is entirely URL-safe — no encoding needed in query strings, paths, or filenames. The alphabet is also case-insensitive, which helps in case-insensitive file systems and user-facing contexts.