Bulk UUID / ULID Generator

A UUID (Universally Unique Identifier) is a 128-bit value used as a database primary key, message ID, or correlation token when you need an identifier that is unique without a central coordinator. A ULID solves the same problem but encodes a timestamp at the front, so the IDs sort in creation order — handy for time-ordered records and index locality. This free tool generates either kind in bulk, entirely in your browser.

How it works

UUID v4 is built from 122 random bits with six bits fixed to mark the version (4) and variant (RFC 4122). This tool calls crypto.randomUUID() when the browser provides it, and otherwise fills 16 random bytes from crypto.getRandomValues() and sets the version and variant bits manually.

ULID is a 26-character string in Crockford base32. The first 10 characters encode the current time as a 48-bit count of milliseconds since the Unix epoch; the remaining 16 characters carry 80 bits of randomness. Because the timestamp leads, ULIDs created later always sort after earlier ones.

Choosing between UUID v4 and ULID for your use case

The right format depends on what you are using the IDs for:

UUID v4 is the right choice when:

• You need IDs to be entirely opaque — revealing nothing about creation order, timing, or any other attribute.
• You are using an existing system that expects RFC 4122 UUIDs (most ORMs, PostgreSQL’s uuid type, MongoDB’s UUID BSON type).
• You are distributing ID generation across multiple sources and want zero coordination.

ULID is the right choice when:

• You want IDs to sort chronologically without a separate created_at column.
• You are optimizing B-tree index performance: because new ULIDs always sort after existing ones, they insert at the end of an index rather than scattering across it. This reduces page splits and keeps indexes compact over time.
• You want IDs to be more human-readable (Crockford base32 is shorter and avoids ambiguous characters like 0, O, I, l).

A useful middle ground is UUID v7 (see the UUID Generator & Validator tool), which combines the RFC 4122 format with a leading millisecond timestamp — you get UUID compatibility plus the sort ordering of ULIDs.

How bulk generation differs from single generation

Generating one UUID at a time is trivial. Bulk generation for database seeding or test data has additional considerations:

Uniqueness guarantees. With 122 random bits per UUID, a batch of 100,000 values has a collision probability so small it is not practically worth considering. The math: roughly 1 in 10^18 chance of any collision in a batch of 100,000.

Performance. This tool generates IDs in pure browser JavaScript. For batches below 100,000 this is fast enough for any practical purpose; larger batches should use a server-side generator or a compiled utility.

Export formats. The CSV download includes an index column, which is useful when you are seeding a database and need to JOIN the new IDs back to their source rows. The TXT format is simpler — one ID per line — for use with COPY commands or bulk import tools.

Practical seeding workflow

For example, to seed 1,000 user IDs into a PostgreSQL table:

1. Generate 1,000 UUID v4 values and download as CSV.
2. Use the COPY command to load the CSV into a staging table.
3. INSERT INTO users (id, ...) SELECT id, ... FROM staging.

This avoids generating IDs in the application layer and ensures every row has a stable, pre-known identifier before the insert.

Notes

A UUID v4 looks like f47ac10b-58cc-4372-a567-0e02b2c3d479, while a ULID looks like 01ARZ3NDEKTSV4RRFFQ69G5FAV. All generation uses crypto.randomUUID() or crypto.getRandomValues() — cryptographically secure, never Math.random(). Nothing is uploaded; close the tab and all generated values are gone.