More games at WuGames.ioSponsoredDiscover free browser games — play instantly, no download, no sign-up.Play
Generator Tools GeneratorDeveloper Tools DeveloperData Tools Data

UUID Batch Generator

Generate up to 10,000 UUIDs: random v4, time-ordered v7, deterministic name-based v5 (namespace + name). Export TXT, CSV, JSON or SQL INSERT.

Between 1 and 10,000

What is the UUID Batch Generator?

A free browser tool to generate Universally Unique Identifiers (UUIDs) in bulk. A UUID is a 128-bit identifier written as 36 characters in canonical form — 32 hexadecimal digits plus four hyphens in the 8-4-4-4-12 pattern (e.g. 550e8400-e29b-41d4-a716-446655440000) — used to uniquely tag database rows, distributed system events, user sessions and files across machines without coordination. This generator supports five versions defined by RFC 9562 (the 2024 standard that supersedes RFC 4122): v1 (timestamp + node), v4 (purely random — the most common), v5 (deterministic, name-based via SHA-1 from a namespace + name), 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
  • Five RFC 9562 versions: v1 (time), v4 (random), v5 (name-based), v7 (time-ordered), v8 (custom)
  • Deterministic v5: feed a namespace (DNS/URL/OID/X.500 or custom) plus a name list — same input always yields the same UUID
  • 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: random v4, time-ordered v7, deterministic name-based v5 (namespace + name). Export TXT, CSV
UUID Batch Generator

How to Use

  1. Pick a version: v4 for general purpose, v7 for database keys, v5 for deterministic name-based IDs, v1 for a legacy time-based ID
  2. For v4/v7/v8/v1: enter a count from 1 to 10,000. For v5: choose a namespace and paste one name per line
  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.

Use v5 whenever you need a deterministic, reproducible ID derived from a natural key — an email, SKU, URL, file path, or a tenant+resource string. v5 is the SHA-1 hash of a namespace UUID concatenated with a name, so the same namespace + name always produces exactly the same UUID, on any machine, forever. That makes it perfect for idempotent ETL and data imports (re-running a load never creates duplicate rows), deduplication, deriving a stable primary key without a lookup table, and generating predictable event/document IDs. Pick the right namespace: DNS for hostnames, URL for URLs, OID for object identifiers, X.500 for directory names, or supply your own custom namespace UUID to scope IDs to your application. v5 (SHA-1) is preferred over the older v3 (MD5); both are name-based but SHA-1 is the modern recommendation. Note v5 is NOT random — never use it as a secret token, because anyone who knows the namespace and name can recompute the UUID.

A UUID is 128 bits = 16 bytes. Stored as canonical text it needs CHAR(36) (or 32 with no dashes), but stored natively it is only 16 bytes — more than 2x smaller, which shrinks every index page and speeds up joins and lookups. Use the native type: PostgreSQL uuid (16 bytes), MySQL/MariaDB BINARY(16) with UUID_TO_BIN()/BIN_TO_UUID(), SQL Server uniqueidentifier, Oracle RAW(16). The bigger win for write-heavy tables is ordering: random v4 keys scatter inserts across the B-tree, causing page splits, index fragmentation and poor buffer-cache locality, while time-ordered v7 keys append near the right edge of the index — benchmarks routinely show v7/sequential UUIDs cutting index bloat and improving bulk-insert throughput several-fold versus random v4 on InnoDB and Postgres. Rule of thumb: store as 16 bytes, and prefer v7 (or v5 when you need determinism) over v4 for clustered/primary keys.

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
GeneratorsGENERATORS104
WuToolsWUTOOLS