What is the difference between UUID v4 and v7?

UUID v4 is entirely random (122 random bits), making it unpredictable and privacy-friendly but causing random B-tree page splits when used as a database primary key at scale. UUID v7 embeds a 48-bit millisecond timestamp in its most significant bits, so generated UUIDs sort lexicographically in creation order. This makes v7 dramatically better for indexed primary keys in large tables while still including 62 bits of randomness to prevent collisions.

Is UUID v1 safe to use publicly?

Classic v1 implementations embedded the generating machine's MAC address in the node field, which leaks hardware identity and was used to de-anonymize the Melissa worm author. Modern implementations (including this generator) use a random 48-bit node instead, eliminating that privacy risk. However, v1 UUIDs still expose the creation timestamp in their structure, which may or may not be acceptable depending on your use case.

Can two UUIDs ever collide?

In theory yes, in practice essentially never for v4. With 122 random bits the probability of a collision between any two v4 UUIDs is about 1 in 5.3 × 10^36. You would need to generate roughly 2.7 × 10^18 UUIDs before the collision probability reaches 50%. For v7, two UUIDs generated within the same millisecond on the same machine could theoretically collide in the random suffix (62 bits), but the odds remain astronomically small.

Should I store UUIDs as strings or binary in my database?

Binary (16 bytes / BINARY(16) in MySQL, or uuid type in PostgreSQL) is more efficient than the 36-character string representation. PostgreSQL's native uuid type stores the value as 16 bytes and handles comparisons efficiently. MySQL lacks a native UUID type, so you should store as BINARY(16) using UNHEX(REPLACE(uuid, '-', '')) on insert and HEX() on select. The string form is fine for low-volume tables where storage and index size are not a concern.

Why is UUID v7 better than UUID v4 for database primary keys?

B-tree indexes work best when new rows are inserted at the end (the rightmost leaf page). With v4 UUIDs, each insert lands at a random position in the index, causing frequent page splits, fragmentation, and heavier write amplification. With v7's monotonically increasing timestamp prefix, new rows always go to the right end of the index — the same pattern as an auto-increment integer. This can reduce index write overhead by 50-80% in high-insert-rate workloads.

Do hyphens in a UUID matter?

Hyphens are part of the canonical UUID string representation (RFC 4122 / RFC 9562) but carry no data. They are purely formatting. Most UUID parsers accept both hyphenated (3839d769-a6de-4a65-a4c2-30cc4de01490) and unhyphenated (3839d769a6de4a65a4c230cc4de01490) forms. What matters is consistency: pick one format for your project and normalize on both write and read to avoid case-sensitivity or formatting mismatches in lookups and joins.

UUID Generator (v1, v4, v7) — Smttooling

🆔 UUID Generator v1 · v4 · v7

UUID Version Count (1 – 100)

Output

Click "Generate UUIDs" to produce your batch

v1 — 100ns timestamp + random node v4 — cryptographically random v7 — ms-sortable + random suffix

UUID v1, v4, and v7 Explained — A Developer's Practical Guide

Every time you create a database record, a file upload, a session token, or an API resource, you need an identifier that is unique across every machine in your fleet, forever. UUIDs (Universally Unique Identifiers) solve exactly this problem — and not all UUIDs are created equal. The version you choose has real consequences for database performance, debuggability, and security.

This guide walks you through the three most useful UUID versions in 2025 — v1, v4, and v7 — explains how each one actually works under the hood, and tells you exactly which version to reach for in each situation.

What Is a UUID, Structurally?

A UUID is 128 bits of data, conventionally displayed as 32 hexadecimal characters split into five groups: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M position (group 3, first character) is the version digit. The N position (group 4, first character) encodes the variant — for the RFC 4122 / RFC 9562 standard it is always 8, 9, a, or b, meaning the top two bits are 10 in binary.

That is the entire structure. Everything else — whether the remaining bits encode a timestamp, a MAC address, or pure randomness — depends on the version.

UUID v4 — Pure Randomness, Zero State

UUID v4 is the most widely deployed version. Exactly 122 of its 128 bits are set by a cryptographically secure random number generator (CSPRNG). The remaining 6 bits are reserved for the version nibble and the variant bits. An example looks like this:

3839d769-a6de-4a65-a4c2-30cc4de01490

Because it is pure random, v4 requires no coordination between machines. There is no shared clock, no central counter, no MAC address exposure. The collision probability for a single pair of v4 UUIDs is approximately 1 in 5.3 × 10³⁶ — effectively zero for any real workload.

When to use v4: Default choice for primary keys when you are starting fresh, for API tokens, session IDs, file upload keys, and anything where you need opaque identifiers. The randomness also means v4 UUIDs do not leak information about when a record was created — useful for public-facing IDs.

The one drawback: Because v4 UUIDs are completely random, inserting them as primary keys in a B-tree index (like PostgreSQL's default btree or MySQL's InnoDB) causes frequent page splits. At high insert rates this becomes measurable. Enter v7.

UUID v7 — Sortable and Modern

UUID v7 was formally standardized in RFC 9562 (2024). It packs a 48-bit Unix millisecond timestamp into the most significant bits, followed by a version nibble, 12 random bits (rand_a), a 2-bit variant marker, and 62 random bits (rand_b). The structure looks like:

019ef821-369d-7142-81a0-d62243d447c4
         ↑    ↑                      ↑
    ms timestamp  version=7     random suffix

The 48-bit timestamp in the first group means that when you sort v7 UUIDs lexicographically, they come out in the order they were generated — to the millisecond. Two UUIDs generated in the same millisecond are disambiguated by the random suffix. This property makes v7 an excellent drop-in replacement for auto-increment integers when you want globally unique IDs without a centralized sequence.

Database performance: Because new UUIDs are always larger than old ones (later timestamp), they always append to the rightmost page of the index. B-tree page splits stop. Benchmarks on PostgreSQL with UUID v7 keys show insert throughput comparable to BIGSERIAL while retaining global uniqueness. Libraries like uuid_generate_v7() in pg_uuidv7 or the built-in support in Postgres 17+ make adoption straightforward.

When to use v7: New greenfield projects, microservice event logs where ordering matters, any table that will grow beyond a few million rows and is indexed on the primary key, and distributed systems where you want to recover approximate creation time from the ID itself without a separate created_at column query.

UUID v1 — Time-Based with Node Identity

UUID v1 is the oldest version and the most information-rich. It encodes a 60-bit timestamp counting 100-nanosecond intervals since October 15, 1582 (the start of the Gregorian calendar — a quirky but intentional choice), a 14-bit clock sequence to handle rapid generation or clock resets, and a 48-bit node identifier.

Originally the node was meant to be the MAC address of the generating machine, which guaranteed uniqueness across machines without coordination. However, embedding a MAC address is a significant privacy concern — it was famously used to trace the author of the Melissa worm. Modern implementations use a cryptographically random node instead, sacrificing true uniqueness guarantees for privacy.

A v1 UUID looks like:

ab5e7710-6f8e-11f1-b8eb-41dc2350fc71

Note that the timestamp is stored in a peculiar byte order: time_low (32 bits) comes first, then time_mid (16 bits), then time_hi (12 bits) with the version nibble. This means v1 UUIDs are not directly sortable as strings — the timestamp is scrambled across the groups.

When to use v1: Legacy systems that already use v1, or niche cases where you need the embedded timestamp and are comfortable parsing it back out. For new work, v7 is strictly better: it is also time-ordered, actually sortable, and does not have the odd timestamp byte ordering.

Formatting Options — Case and Hyphens

The canonical UUID format is lowercase with hyphens, as specified in RFC 4122. Both uppercase and hyphen-stripped variants are widely accepted, but you should pick one and enforce it consistently throughout a project. Storing 3839D769A6DE4A65A4C230CC4DE01490 in one service and 3839d769-a6de-4a65-a4c2-30cc4de01490 in another will cause lookup failures if you ever join or compare without normalization.

The hyphen-stripped format saves 4 bytes per UUID in storage and network transfer — negligible in most cases but occasionally relevant in high-throughput event streams or fixed-width binary formats. Some systems (notably Microsoft COM/OLE) traditionally use uppercase with curly braces; most web APIs expect lowercase with hyphens.

Generating UUIDs in Code

In modern environments, UUID generation is built-in or one import away. In Node.js 19+ and all modern browsers, crypto.randomUUID() generates a cryptographically secure v4 UUID with no dependencies. In Python, the uuid module in the standard library covers v1, v3, v4, and v5 — and third-party packages like uuid7 add v7. In Go, the google/uuid package added v7 support in v1.6. PostgreSQL users can install the pg_uuidv7 extension or use Postgres 17's native uuidv7() function.

Quick Decision Guide

If you need simplicity and privacy, use v4. If you need index performance and time ordering in a new project, use v7. If you are maintaining a legacy system that already uses v1, keep using v1 — migrating UUID versions mid-project is painful without a clear benefit. Never roll your own UUID algorithm; the bit-level details of version nibbles and variant markers are easy to get slightly wrong in ways that cause subtle collisions or interoperability failures with strict parsers.

The generator above handles all three versions in pure client-side JavaScript using crypto.getRandomValues() for all random bytes, so nothing is ever sent to a server. Generate your batch, choose your format, and copy — ready to paste into your migration file, Postman, or seed script.

🆔 UUID Generator (v1, v4, v7)