UUID Generator Comparison: v1 vs v4 vs v7

Updated 2026-08-31 · 3 min read

Which UUID version should you generate?

A UUID is a 128-bit identifier written as 36 characters, for example 3f2504e0-4f89-41d3-9a0c-0305e82c3301. All versions share that shape, but they differ in how the bits are filled — and that decides whether your identifiers are random, sortable, or leak information about the machine that created them.

For nearly all application code the answer is v4 (fully random) or v7 (time-ordered). Choose v4 when the identifier is public and must reveal nothing. Choose v7 when the identifier is a database primary key and you care about index locality and chronological sorting.

Version comparison table

The practical differences that matter when picking a generator:

• v1 (timestamp + MAC) — sortable-ish, but embeds the host MAC address and clock. Avoid for anything user-facing; it leaks infrastructure detail.
• v3 / v5 (name-based hash) — deterministic: the same namespace + name always yields the same UUID. Useful for idempotent imports and de-duplication, not for new records.
• v4 (random) — 122 random bits, no metadata, effectively zero collision risk. The safest default for public IDs, API keys' subject IDs, file names and share links.
• v6 — v1 reordered so the timestamp sorts lexicographically. Mostly a migration path for existing v1 data.
• v7 (Unix time + random) — millisecond timestamp in the high bits, randomness below. Sorts by creation time as text or binary, which keeps B-tree inserts near the right edge of the index.
• ULID — not a UUID, but a 26-character Crockford base32 alternative with the same time-ordering idea. Shorter to read, less tooling support.

Practical example: UUIDs as primary keys

Say you are creating an orders table and want IDs that are safe to expose in a URL. With random v4 keys, every insert lands at a random point in the index, which fragments pages and slows writes on large tables. With v7 keys, inserts append near the end and range scans by time become cheap.

A concrete pair generated for this example — note the shared prefix on the v7 values, which is exactly what makes them sortable:

• v4: b1c2f0e8-9a44-4d1c-8f2a-7c5d61e0aa39
• v4: 0e7ab41d-2f6b-4c99-b3d7-51f9a08c6b12 (no relationship to the one above)
• v7: 0192f3a1-7c40-7b2e-9c31-4a6e2f8b7d10
• v7: 0192f3a1-8e11-7f05-a7c2-19b4c0d3e6a8 (created moments later, sorts after)

Generating them in code

In modern browsers and Node.js, crypto.randomUUID() returns a v4 UUID with no dependency. In PostgreSQL, gen_random_uuid() does the same server-side, so a column can default to it. For v7 you currently need a small library (for example uuid v10+ with uuidv7()) or a SQL function, because it is newer than most built-ins.

Store UUIDs in a native uuid column, never as varchar(36): the binary form is 16 bytes instead of 36 and compares far faster.

How online UUID generators differ

Most 'UUID generator' pages fall into three groups. Server-side generators build the value on their backend, which means the identifier travelled the network before you used it. Ad-heavy generators wrap a one-line call in trackers. Client-side generators run crypto.randomUUID() in your own tab, so the value never leaves your machine.

When you are generating a key that will protect a resource, the third group is the only defensible choice — and it is also the fastest, since there is no round trip.

Are collisions a real risk?

For v4, no. There are 2^122 possible values; you would need to generate roughly 2.6 × 10^18 UUIDs before a 50% chance of a single collision. The realistic failure mode is not mathematics but a weak random source — a generator falling back to Math.random() instead of the cryptographic API. That is why the implementation matters more than the version.

Generate UUIDs now

Use the UUID Generator to create single or bulk UUIDs in your browser, then validate their shape with the Regex Tester or hash them with the Hash Generator if you need a shorter derived key.

Frequently asked questions