UUID Generator — Bulk v1, v4 & v7 (RFC 9562) Online

UUID Generator

Conditions

Results

1

About the UUID Generator

Overview

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.

How 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.

Specifications & 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.

Use 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.