Generator Tools GeneratorDeveloper Tools DeveloperData Tools Data

UUID Batch Generator

Generate up to 10,000 UUIDs in versions 1, 4, 7 or 8. Export as TXT, CSV, JSON or SQL INSERT VALUES. Time-ordered v7 for DB primary keys.

Between 1 and 10,000

What is the UUID Batch Generator?

A free browser tool to generate Universally Unique Identifiers (UUIDs) in bulk. UUIDs are 128-bit identifiers used to uniquely tag database rows, distributed system events, user sessions and files across machines without coordination. This generator supports the four most useful versions defined by RFC 9562 (the 2024 standard that supersedes RFC 4122): v1 (timestamp + node), v4 (purely random — the most common), v7 (time-ordered Unix-ms — perfect for database primary keys) and v8 (custom layout). Everything runs in your browser using the WebCrypto API, so no data ever leaves your device.

Key Features

  • Generate up to 10,000 UUIDs in one click — fast in-browser generation
  • Four RFC 9562 versions: v1 (time), v4 (random), v7 (time-ordered), v8 (custom)
  • v4 uses native crypto.randomUUID() when available (cryptographically secure)
  • v7 embeds Unix milliseconds in the first 48 bits — sortable, indexable, ideal for primary keys
  • Case toggle (lower / UPPER) and format toggle (dashed / plain / {braced})
  • Export as plain TXT, CSV, JSON or SQL INSERT INTO ... VALUES (...) syntax
  • Privacy-safe: v1 uses random multicast node bits (never reveals real MAC address)
  • 100% browser-side — no server roundtrip, no telemetry
UUID Batch Generator — Generate up to 10,000 UUIDs in versions 1, 4, 7 or 8. Export as TXT, CSV, JSON or SQL INSERT VALUES. Time-ordered v7 for
UUID Batch Generator

How to Use

  1. Pick a version: v4 for general purpose, v7 for database keys, v1 if you need a legacy time-based ID
  2. Enter a count from 1 to 10,000
  3. Optionally switch case to UPPER and format to plain or {braced}
  4. Click Generate UUIDs — the list appears instantly in the textarea
  5. Copy all to clipboard or download as TXT, CSV, JSON or SQL INSERT statements
  6. Paste the SQL block directly into your database client to bulk-insert IDs

Frequently Asked Questions

v4 is 122 random bits with 6 fixed version/variant bits — fully unpredictable but has no inherent order, so inserting v4 keys into a B-tree index causes random page writes and index fragmentation. v7 is RFC 9562's modern replacement: the first 48 bits are the Unix timestamp in milliseconds, the rest is random. v7 IDs sort chronologically as strings AND as binary, so they cluster well in B-tree indexes (PostgreSQL, MySQL InnoDB, SQL Server). They also preserve creation-time information without an extra column. Use v7 for primary keys in new schemas; use v4 for opaque public-facing IDs (URLs, API keys) where you don't want creation time leaked.

Practically, yes. A v4 UUID has 122 bits of randomness, giving 2^122 ≈ 5.3 × 10^36 possible values. By the birthday paradox, you'd need to generate roughly 2.71 quintillion (2.71 × 10^18) UUIDs before the probability of a single collision reaches 50%. Even at 10,000 IDs per second nonstop, you'd hit 50% collision probability after ~9 trillion years. For all practical purposes — including planet-scale systems — v4 is collision-proof. Just don't use Math.random()-based generators; this tool uses crypto.getRandomValues() which is the WebCrypto CSPRNG.

The original RFC 4122 v1 spec encodes the generator's network MAC address into the last 48 bits, which leaks identity (a single v1 UUID can be tied back to a specific machine — this was famously used to identify the author of the Melissa virus in 1999). Our generator follows the modern best practice: we randomize the node bits and set the multicast bit, signaling that this is NOT a real hardware address. So a v1 ID from this tool is privacy-safe — you get time-ordered ID with no MAC leak.

v8 is the 'custom layout' version: RFC 9562 reserves it for application-specific structures. The only required bits are the version nibble (8) and the variant bits. You're free to encode anything else into the remaining 122 bits — a tenant ID prefix, a sharding hint, a fixed signature. This generator outputs a v8 with the same time-ordered layout as v7, just relabeled, which is a common pattern when you want time-ordering plus a 'don't parse as v7' marker. For production v8, design your own layout and document it.

Yes. PostgreSQL has a native uuid type; use SQL export and INSERT INTO table (id) VALUES ('uuid-here'); — or download CSV and use COPY. MySQL uses CHAR(36) or BINARY(16) (faster); UUID_TO_BIN(uuid_string, 1) reorders v1 for index locality (not needed for v7 — it's already sortable). MongoDB stores UUIDs as Binary subtype 4; in mongosh: db.col.insertMany([{id: UUID('uuid-here')}, ...]). For SQL Server use uniqueidentifier; for Oracle RAW(16) with SYS_GUID() or your supplied value.

v4 yes (122 bits of CSPRNG entropy = far more than a 128-bit symmetric key). v1, v7 and v8 are NOT safe as bearer tokens because they leak the creation timestamp and have less randomness (62-77 random bits depending on version). If an attacker can observe one v7 ID and guess approximately when an account was created, they can narrow the search space significantly. For session tokens, password reset links, API keys: use v4 or a dedicated CSPRNG token (e.g. 32 hex chars from crypto.getRandomValues), not v1/v7/v8.

10,000 hits a sweet spot: large enough for almost any bulk-seed scenario (database test fixtures, migration scripts, load tests), small enough to render in the textarea without browser freeze. A typical browser generates 10,000 v4 UUIDs in 20-80ms using crypto.randomUUID(). If you need 1M+ UUIDs (e.g. for a one-off migration), run this generator in a loop and stream the SQL exports into your database client, or use a server-side script — UUID generation parallelizes trivially since each ID is independent.
See also
GeneratorsGENERATORS103
WuToolsWUTOOLS