infoOverview

Writing one-off test fixtures or seeding a database with sample primary keys shouldn't require spinning up a script just to call a UUID library. This generator produces RFC 9562-compliant UUIDs directly in the browser — choose from the classic random v4, the timestamp-based v1, or the newer time-ordered v7 — and can output up to 1,000 at once for bulk seeding.

A shared auto-increment counter turns into a single point of contention the moment multiple servers or services need to mint IDs at once, forcing coordination that a purely random or timestamp-based scheme doesn't need. UUIDs sidestep that by letting every node generate a unique value independently, which is part of why they're a default choice in distributed architectures — and this page doubles as a quick way to eyeball what each version looks like before wiring one into your code.

checklistHow to Use

1. 1Pick a Version — v1, v4, or v7 — under Conditions. Not sure which one fits? See the version comparison below.
2. 2Set Number of UUIDs to however many you need, up to 1,000 per batch.
3. 3Click Generate and the full list appears under Results.
4. 4Copy the list straight from Results — one UUID per line, ready to paste into a seed script or test fixture.

Tip: if you're unsure which version to pick, go with v7 for a brand-new system (it sorts chronologically), or v4 if compatibility with existing tooling matters more — it's the most widely supported.

menu_bookSpecifications & Glossary

• Format: Every UUID is a 128-bit value written as xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M digit identifies the version (1, 4, or 7 here), and the leading bits of N identify the variant — this is how a parser can tell at a glance which generation rules were used.
• UUID v1 (time-based): Combines a 60-bit timestamp with a MAC address or random node identifier. Sorts roughly chronologically, but because it can leak the generating machine's MAC address, it's rarely chosen for new systems today.
• UUID v4 (random): 122 bits of randomness with no embedded metadata, making it the safest default when you don't want an identifier to reveal anything about when or where it was created. Still the most common choice across language standard libraries, with a collision probability low enough to ignore in practice (1 in 2^122).
• UUID v7 (time-ordered): A millisecond-precision Unix timestamp in the high bits followed by random bits, standardized in RFC 9562. In the "UUID v4 vs v7" debate, v7 wins for primary keys: because values generated close together sort close together, B-tree indexes stay compact instead of fragmenting the way they do with purely random v4 keys.
• Collision probability: Even after generating 10 trillion v4 UUIDs, the chance of any two matching stays below 0.00000001% — low enough that you don't need a uniqueness check before inserting one into a database.
• Choosing a version: v1 has fallen out of favor because it can leak the generating machine's MAC address, pushing most new projects toward either random v4 or time-ordered v7. RFC 9562 (published 2024) formalized that shift, standardizing v6, v7, and v8 alongside the original v1 and v4 and giving implementers clearer guidance on which to reach for.
• Variant bits: The 17th character (the N position) is always 8, 9, a, or b in an RFC 4122-conformant UUID. A different value there usually signals a UUID built to a different, non-standard scheme, such as Microsoft's legacy GUID variant.

lightbulbUse Cases

• Seeding sample primary keys or record IDs for a development or staging database.
• Creating session IDs or request trace IDs for distributed systems.
• Generating unique filenames for uploads, or correlation IDs that tie a request together across microservices.
• Weighing UUIDs against auto-increment integers or ULIDs for a primary key: UUIDs let you generate IDs client-side and avoid leaking row counts, at the cost of index size and (for v4) random insert order — a trade-off worth testing here before committing to a schema.
• Bulk-generating a few hundred or a thousand unique user IDs or order IDs at once for a database seed script when setting up test data in a development environment.
• Minting a UUID for an Idempotency-Key header on requests that need idempotency guarantees, such as payment API calls, so the same key can be safely retried without double-processing.

quizFAQ

Which UUID version should I use: v1, v4, or v7?

For a database primary key in a new system, v7 is the strongest default — it sorts chronologically and keeps index fragmentation low. If library support or compatibility with an existing system matters more, v4 is the safest bet since it's the most widely implemented. Avoid v1 for new work; it can embed the generating machine's MAC address.

Can two generated UUIDs ever collide?

Not in practice. v4 draws from 122 bits of randomness, so even generating a billion per second continuously, the odds of ever seeing a duplicate stay astronomically low.

Are the UUIDs I generate stored on this tool's server?

No. Generation happens entirely in client-side JavaScript, so the results are never sent to or stored on a server. Reload the page and the batch you generated is gone.

Should I use a UUID or an auto-increment integer as my primary key?

UUIDs make sense when multiple nodes create records independently, or when you don't want an ID to leak row counts or creation order. If you're on a single database and index size or JOIN performance is the priority, an auto-increment integer can still win. Using v7 gets you most of the UUID benefits with index locality closer to what an integer key gives you.

Why is the batch size capped at 1,000?

It's a practical limit for keeping the results readable and easy to copy in the browser. For anything larger, generate them directly in a script using Node's crypto module or the uuid package instead.

Can I get the output without hyphens, or in uppercase?

The current output is always the standard lowercase, hyphenated form defined by RFC 4122. If you need hyphens stripped or the letters uppercased, run a find-and-replace on the copied text afterward.