UUID Studio

Bulk UUID Generator

Generate many UUID v4s for testing.

  • đź”’ No data stored or uploaded
  • ⚡ 100% client-side
  • 🆓 Free, no account

Need more than one tool at a time? Open the full Workbench - or press Ctrl+K to jump to any tool.

Click Convert when ready

Override only when Auto cannot parse your paste. Changing this loads a matching sample into Input — click Convert to run. Use Load sample to cycle every format example.

All conversions

Read-only representations of the same 16 bytes. Every textual form is listed here, not in “Prefer format”.

About Bulk UUID Generator

Generates many UUID v4 values at once, using the same cryptographically secure source as the single generator - crypto.getRandomValues, not Math.random(). Useful when you need to seed a table, build a fixture file, or load-test something that expects distinct identifiers.

Every value is independent. There is no counter, no sequence and no shared state, so the list has no order and reproduces none: generating the same count twice gives a completely different set. If you need reproducible identifiers for a test, derive them with UUID v5 from a fixed namespace and name instead.

The collision arithmetic makes bulk generation comfortable. Even generating a billion v4 UUIDs leaves the probability of any pair colliding at roughly one in 10^22, so you do not need to deduplicate the output - though the tool does not stop you checking.

Bear in mind what a large batch of random keys does to a database. Inserting a million v4 UUIDs into a clustered index scatters writes across the whole structure and is markedly slower than inserting a million sequential values. For bulk-loading real data, UUID v7 or ULID will load faster and leave a less fragmented index.

All generation is local, so a batch of 10,000 costs one burst of CPU and no network at all.

How to use the Bulk UUID Generator

  1. Set how many UUIDs you want.
  2. Generate, then copy the block or download it.
  3. Pick the output shape that matches where it is going - one per line for a file, quoted and comma-separated for a SQL IN clause or a code literal.
  4. If these are going to become primary keys in a large table, consider generating ULIDs or v7 UUIDs instead so the bulk insert keeps index locality.

Examples

  • Generate 5 UUIDs
    5

Bulk UUID Generator in code

The same operation this tool performs, in the languages you are most likely to need it.

JavaScript
// Straightforward
const ids = Array.from({ length: 10_000 }, () => crypto.randomUUID());

// Much faster for very large batches: one call into the CSPRNG
// instead of 10,000, then format the bytes yourself.
function bulkUuidV4(count) {
  const buf = crypto.getRandomValues(new Uint8Array(16 * count));
  const out = new Array(count);
  for (let i = 0; i < count; i++) {
    const b = buf.subarray(i * 16, i * 16 + 16);
    b[6] = (b[6] & 0x0f) | 0x40;
    b[8] = (b[8] & 0x3f) | 0x80;
    const h = [...b].map((x) => x.toString(16).padStart(2, "0")).join("");
    out[i] = `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`;
  }
  return out;
}
Python
import uuid

ids = [str(uuid.uuid4()) for _ in range(10_000)]

with open("ids.txt", "w") as f:
    f.write("\n".join(ids))

# Reproducible identifiers for a test fixture - same input,
# same UUID, every run:
ns = uuid.UUID("6ba7b810-9dad-11d1-80b4-00c04fd430c8")   # NAMESPACE_DNS
fixed = [str(uuid.uuid5(ns, f"user-{i}")) for i in range(100)]
SQL
-- PostgreSQL: generate 10,000 rows directly
INSERT INTO things (id)
SELECT gen_random_uuid() FROM generate_series(1, 10000);

-- Time-ordered instead, for a much friendlier bulk insert
-- (PostgreSQL 18+; use a ULID extension on older versions)
-- SELECT uuidv7() FROM generate_series(1, 10000);

-- MySQL 8+
INSERT INTO things (id)
SELECT UUID_TO_BIN(UUID(), 1) FROM some_table LIMIT 10000;
Command line
# 10,000 UUIDs, one per line
python3 -c "import uuid; print('\n'.join(str(uuid.uuid4()) for _ in range(10000)))" > ids.txt

# From the Linux kernel, no Python needed
for i in $(seq 1 10000); do cat /proc/sys/kernel/random/uuid; done > ids.txt

# Quoted and comma-separated, ready for a SQL IN clause
awk '{printf "%s'\''%s'\''", (NR>1?",":""), $0}' ids.txt > ids.sql

When you need this

  • Seeding a development or staging database with realistic identifiers.
  • Building a fixture file for tests that need many distinct IDs.
  • Generating load-test payloads where each request needs a unique idempotency key.
  • Pre-allocating identifiers to insert in one batch rather than row by row.
  • Producing a list of unguessable names for objects in blob storage.

Common problems and what causes them

Bulk-inserting random UUIDs as clustered primary keys
Random keys land all over the index, so a large batch causes constant page splits and a fragmented index - noticeably slower than the same number of sequential inserts. Use ULIDs or v7 UUIDs for bulk loads, or load into a staging table and build the index afterwards.
Expecting the same list twice
Each value is independently random, so there is nothing reproducible about the output. Tests that need stable identifiers should use v5 UUIDs derived from a fixed namespace and name, or a checked-in fixture file.
Generating an enormous batch in one browser tab
Hundreds of thousands of values will allocate a lot of memory and may make the tab unresponsive while it formats strings. For very large volumes, generate them where they are going to be used - the SQL and shell snippets above do it without a browser.
Deduplicating the output 'just in case'
Harmless but pointless: the probability of a collision within any batch you could produce here is astronomically small. If you do find duplicates, the bug is in how the list was assembled or copied, not in the generator.

FAQ

How many UUIDs can I generate at once?
Tens of thousands comfortably. Beyond that the limit is your browser's memory and the cost of building that many strings, so for very large volumes generate them directly in SQL or a script - see the snippets above.
Could there be duplicates in a large batch?
Effectively no. Across a billion v4 UUIDs the chance of any pair matching is around one in 10^22. A duplicate in practice means the list was concatenated or copied twice.
Are these suitable for database primary keys?
They are valid keys, but random UUIDs are a poor fit for a clustered index at scale because inserts scatter. If the table will grow large, prefer time-ordered identifiers - UUID v7 or ULID - which keep the same properties while appending to the end of the index.
Can I get them without hyphens, or as Base64?
Yes - the same 128 bits can be written as 32 hex characters or as 22 unpadded Base64 characters. Use the UUID converter to re-encode a value losslessly between representations.
Maximum count?
500 per run to keep the tab responsive.

Related reading