What Is a UUID? UUID v4 vs v7 Explained

A UUID — Universally Unique Identifier — is a 128-bit label formatted as a 32-character hexadecimal string, standardized to look like 550e8400-e29b-41d4-a716-446655440000. UUIDs are designed to be unique across every computer and every moment in time without any central authority handing them out. That property makes them the go-to ID format for distributed systems, databases, APIs, and anywhere else a collision-safe identifier needs to be generated independently.

The anatomy of a UUID

Every UUID contains 32 hexadecimal digits split by four hyphens into five groups in the pattern 8-4-4-4-12. The full string is always 36 characters long (32 hex digits plus four hyphens):

The 128 bits of data in a UUID translate to roughly 3.4 × 10³⁸ possible values — far more than the number of atoms on Earth. That enormous space is what makes collisions practically impossible even when IDs are generated by millions of independent processes.

UUID v1: time and machine identity

UUID version 1 was the original standard. It constructs the identifier from two main ingredients: a 60-bit timestamp (based on a 100-nanosecond intervals since October 15, 1582 — the adoption date of the Gregorian calendar) and the MAC address of the network interface that generated the UUID.

The timestamp makes v1 UUIDs monotonically increasing on a single machine, which is useful for database index locality — sequential inserts into a B-tree index cause fewer page splits than random inserts. The downside is significant: embedding a MAC address leaks network identity information, which is a privacy concern for any UUID that will appear in a public API or URL. For this reason, v1 fell out of favor in web-facing applications during the 2010s.

UUID v4: pure randomness

UUID version 4 is the most widely used format today. It sets the version nibble to 4 and fills the remaining 122 bits with cryptographically secure random data. There is no timestamp, no machine identity, no sequence — just randomness.

A v4 UUID generated in JavaScript using the standard Web Crypto API looks like this:

With 122 random bits, the probability of generating two identical v4 UUIDs is vanishingly small. To put it concretely: if you generated one billion UUIDs per second for 100 years, the probability of even a single collision is still less than one in a billion. For nearly every real-world application, v4 UUIDs can be treated as globally unique without qualification.

The practical downside is index fragmentation. Because each v4 UUID is random, inserting rows keyed by v4 UUID into a database B-tree index scatters writes across the index rather than appending to the end. At large scale this causes index bloat and slower write performance. If you are inserting millions of rows per day, this matters.

UUID v7: the modern successor

UUID version 7 was formally specified in RFC 9562 (May 2024) and addresses the index-fragmentation problem while preserving the privacy of v4. A v7 UUID is time-ordered: the first 48 bits encode a Unix timestamp in milliseconds, so UUIDs generated close in time sort close together in a B-tree index.

Here is a simplified breakdown of the v7 bit layout:

The result looks like a normal UUID — 018fda87-3920-7a1b-8c2d-3f1a7b4e9d03 — but the leading segment encodes time, so lexicographic sort equals chronological sort. This makes v7 an excellent primary key for append-heavy tables in PostgreSQL, MySQL, and SQLite because new rows always land near the end of the index, keeping writes efficient.

The remaining bits are still random enough (74 bits of randomness within a millisecond window) that collision probability remains astronomically low.

v4 vs v7: which should you use?

The choice depends on where the UUID will live and how it will be queried:

A good rule of thumb: if the UUID is a database primary key for a table that will have more than a few million rows, seriously consider v7. For everything else — API responses, idempotency keys, test fixtures, object names in object storage — v4 is simpler and perfectly sufficient.

UUID vs GUID: are they the same thing?

Essentially yes. GUID (Globally Unique Identifier) is Microsoft's name for the same concept, used throughout Windows APIs and .NET. The underlying format is identical to RFC 4122 UUIDs. The only cosmetic difference is that Microsoft sometimes wraps them in braces: {550e8400-e29b-41d4-a716-446655440000}. When you see GUID in a Windows or Azure context, treat it as interchangeable with UUID.

UUID vs auto-increment: when to choose which

Auto-incrementing integers (1, 2, 3, ...) are smaller (4–8 bytes vs 16 bytes for a UUID), faster to index, and trivial to type. They are fine for simple applications where the database is the only thing generating IDs and the total record count is not sensitive information.

UUIDs become preferable when:

• Multiple services or clients generate IDs independently and then merge data (distributed systems, offline-first apps).
• You want to prevent users from guessing neighboring IDs by incrementing — a UUID in a URL does not reveal how many records exist.
• You need to generate an ID client-side (in a browser or mobile app) before the record reaches the server — useful for optimistic UI updates.
• You are merging or federating data from multiple databases and need IDs to remain unique across sources.

How to generate a UUID right now

In a browser, the modern way is the Web Crypto API, which is available in all current browsers and Node.js 19+:

In Python:

In PostgreSQL, the gen_random_uuid() function (built in since version 13) generates a v4 UUID without any extension. For v7, the uuid_generate_v7() function is available via the pg_uuidv7 extension.

If you just need a UUID quickly — for a config file, a test fixture, a database seed, or to paste into a form — Figro's UUID generator runs entirely in your browser with no signup required.

Figro's guides are educational and independent. They are not professional advice. Some pages include affiliate links; if you purchase through them we may earn a commission at no extra cost to you.