UUID/ULID Generator

Generating unique identifiers is one of those quietly fundamental operations that underpins almost every modern application — database primary keys, correlation IDs that thread through logs across services, file names that need to avoid collisions across users, API resource handles, deduplication tokens, idempotency keys for retry-safe operations. The everyday developer use is narrow but constant: producing a few IDs to populate a test fixture, generating a session token for a one-off integration test, creating a unique handle for a new resource being added by hand. This tool is the local alternative to opening a Python REPL or writing a one-liner shell script every time the need comes up.

UUID v4 is the version most developers default to and for good reason. Each UUID v4 contains 122 bits of randomness drawn from a cryptographically strong source, which makes the probability of generating two identical UUIDs across all the world's systems vanishingly small. The format — 8-4-4-4-12 hexadecimal digits separated by hyphens — is universally supported across databases, programming languages, and serialisation formats. PostgreSQL has a native UUID type; MySQL stores them as CHAR(36) or BINARY(16); MongoDB uses them as document IDs; nearly every web framework recognises the format for primary keys. As a default identifier choice, UUID v4 has the property of working everywhere without specific configuration.

ULID is the alternative that makes sense when chronological sortability matters. The format is 26 characters of Crockford Base32, encoding 48 bits of timestamp followed by 80 bits of randomness. The timestamp prefix means that ULIDs sort roughly chronologically when stored as strings — a property that's enormously useful for event tables, audit logs, and any system where the natural order of records matters. Database indexes on ULID columns also tend to be more efficient than indexes on UUID v4 columns because the time-ordered insertions don't fragment the index the way random insertions do. The trade is that ULIDs leak the rough timestamp of generation, which is sometimes a privacy concern.

There's a more general question about whether to use UUIDs at all that's worth thinking through before reaching for them. Auto-incrementing integer IDs are simpler, smaller, faster, and more efficient as database keys; the case for UUIDs is that they're generated client-side without a database round-trip, they don't reveal the rate of resource creation, they can be created in distributed systems without coordination, and they're not enumerable by attackers who have one valid ID. Different projects weight these differently; UUIDs make sense for distributed systems and public-facing resources, integers make sense for internal-only workflows where the operational simplicity wins.

Bulk generation is the case that distinguishes a complete tool from a single-ID generator. Populating a test database with a thousand fake users requires a thousand UUIDs, which is annoying to do one at a time. The tool here generates configurable counts in a single batch, with deduplication built in (UUID v4 collisions are statistically impossible at any practical batch size, but the deduplication step catches programmer errors like accidentally requesting the same ID twice). The output is a clean newline-separated list ready for paste into SQL inserts, JSON arrays, CSV files, or any other ingestion format.

Format and case considerations matter more than they should because mixing them is a regular source of bugs. UUIDs are typically displayed in lowercase with hyphens (8-4-4-4-12), but they can also appear uppercase, hyphen-less (32 hex characters), or in alternative formats like Base64. Storing UUIDs in different formats across services means string comparisons fail to match what's logically the same ID; canonical lowercase-with-hyphens is the safest default and what most modern systems expect. ULIDs are case-insensitive but uppercase is the canonical form per the spec; lowercasing is technically allowed but produces output that looks subtly different from the spec examples.