UUID v4 vs v1: How to Generate Unique IDs in Bulk (and When to Use Each)

The problem: you need unique IDs, now

You're seeding a database, writing test fixtures, stubbing an API response, or naming resources that must not collide. You need identifiers that are unique without coordinating with a central server. That's the whole point of a UUID (Universally Unique IDentifier, also called a GUID) — a 128-bit value you can generate anywhere and trust to be distinct. When you need ten of them, or a thousand, doing it by hand is a non-starter.

A UUID Generator produces valid v4 and v1 UUIDs in bulk, ready to copy or download, all generated locally in your browser so nothing is logged or transmitted.

What a UUID looks like

A UUID is 32 hexadecimal digits shown in five hyphen-separated groups, 36 characters total:

f47ac10b-58cc-4372-a567-0e02b2c3d479
                ^    ^
                |    variant bits (8, 9, a, or b)
                version digit (here: 4)

The digit at the start of the third group encodes the version, and the first digit of the fourth group encodes the variant. That's how a parser knows a 4 means "randomly generated" and a 1 means "time-based".

v4: random

Version 4 fills almost all 128 bits with random data (122 bits after the fixed version and variant bits). It carries no information about when or where it was made — which is usually exactly what you want for a primary key or a public identifier. The collision odds are famously negligible: you'd need to generate on the order of a billion UUIDs per second for decades before a duplicate became likely. In JavaScript, the platform gives you one directly:

crypto.randomUUID();
// "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d"

v1: time-based

Version 1 combines a timestamp (100-nanosecond intervals since 1582) with a clock sequence and a node identifier, historically the machine's MAC address. Two useful consequences: v1 UUIDs generated in sequence are roughly ordered by time, which can help database index locality, but they can leak the generation time and node. Modern implementations often randomize the node to avoid exposing hardware.

A practical walkthrough: bulk generation

Suppose you need seed data for a users table. Generate a batch of v4 UUIDs and drop them straight into an insert:

INSERT INTO users (id, name) VALUES
  ('a3f1c2d4-1b2e-4c3a-9f8d-7e6b5a4c3d2e', 'Ada'),
  ('b7e9d1a2-3c4f-4d5b-8a1c-2f3e4d5c6b7a', 'Linus'),
  ('c1d2e3f4-5a6b-4c7d-9e8f-1a2b3c4d5e6f', 'Grace');

Pick v4 for the version, set the count, generate, and copy or download the list. For a thousand test records you get a clean column of IDs without writing a loop.

Common pitfalls and tips

• Case and hyphens. UUIDs are case-insensitive; most systems store them lowercase. Some databases accept them without hyphens or in a compact binary column — normalize to whatever your schema expects.
• Don't treat v4 as a secret. A v4 UUID is unpredictable enough to be hard to guess, but it isn't a security token in the cryptographic sense you'd design around. For passwords or API keys, use a Password Generator instead.
• Shorter IDs for URLs. If 36 characters is too bulky for a URL slug, a NanoID Generator produces compact, collision-resistant IDs.
• v1 ordering isn't guaranteed sortable as text. Because the timestamp is split across fields, v1 UUIDs don't sort chronologically as plain strings. If you need lexicographically sortable time IDs, that's a different scheme (like ULID), not v1.

Conclusion

Reach for v4 by default — random, opaque, and collision-safe for practically any workload. Choose v1 only when you specifically want time-embedded, roughly time-ordered identifiers and understand the trade-offs. Generate the batch you need locally, copy it into your fixtures or schema, and move on.