UUID v4 Explained: What It Is, How It Works, and When to Use It

You have seen them everywhere — in database rows, API responses, file names, and URLs. A string like 550e8400-e29b-41d4-a716-446655440000 that looks random because it is. UUID v4 is the default choice for unique identifiers in most modern software, and for good reason. But most developers use it without knowing what the format actually means, why the randomness is safe, or when a different version would serve them better.

This is the explainer that fills that gap.

What UUID v4 actually means

UUID stands for Universally Unique Identifier. The full format is defined by RFC 4122 and always looks like this:

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

Breaking it down:

• 32 hexadecimal characters total
• Split into 5 groups by hyphens: 8-4-4-4-12
• The third group always starts with 4 — this is the version number
• The fourth group always starts with 8, 9, a, or b — this is the variant field, indicating RFC 4122 compliance

The rest — 122 bits — is cryptographically random. That is where the uniqueness comes from.

How the randomness works

UUID v4 does not use your machine name, timestamp, or any identifying information. It is pure random data generated by a cryptographically secure random number generator — crypto.getRandomValues() in browsers, /dev/urandom on Linux, or equivalent system APIs on other platforms.

This has two important implications:

First, v4 UUIDs are unpredictable. Unlike v1 UUIDs (which embed a timestamp and MAC address), there is nothing in a v4 UUID that reveals when or where it was generated. This matters when UUIDs appear in URLs or are exposed to users — an attacker cannot guess adjacent IDs or infer system information from them.

Second, v4 UUIDs are not sequential. Each one is independent of every other. This is by design for security, but it creates a specific problem for databases — more on that below.

You can generate a UUID v4 instantly using the UUID Generator — it runs entirely in your browser with no server involved.

How unique is unique?

There are 2¹²² possible UUID v4 values — approximately 5.3 undecillion (that is 5.3 followed by 36 zeros).

To put a collision in perspective: if you generated one billion UUIDs per second, you would need to run for 85 years before having a 50% chance of a single duplicate. In practice, UUID v4 collisions do not happen. You can safely treat them as unique in any real-world application.

The only exception: if your random number generator is broken or seeded with low entropy (a common problem in some virtualised environments at boot time), uniqueness guarantees degrade. This is rare but worth knowing if you generate UUIDs at VM startup.

UUID v4 vs the other versions

UUID is not one thing — there are seven versions, each with a different generation strategy.

v1 — Time and MAC address based

Generated from the current timestamp and the network interface MAC address. Sortable by creation time, but leaks information about your machine and network. Mostly found in legacy systems and Cassandra databases. Avoid for any user-facing identifier.

v3 and v5 — Name based

Deterministic: the same input always produces the same UUID. v3 uses MD5, v5 uses SHA-1. Useful when you need a stable identifier for a resource that already has a name — for example, generating the same UUID for a given URL every time. Not suitable for primary keys.

v4 — Random

What this article is about. The safe default for primary keys, tokens, session IDs, and file names. No information leakage, no coordination required between systems.

v6 and v7 — Modern time-ordered

v7 is the version to know. It encodes a Unix millisecond timestamp in the most significant bits, making UUIDs generated in sequence roughly sortable. This solves the main database performance problem with v4. If you are starting a new project and want UUID-style IDs as primary keys, v7 is worth serious consideration over v4.

The database performance problem with v4

This is the most important practical consideration for developers.

Relational databases (PostgreSQL, MySQL, SQL Server) store table rows in a B-tree index ordered by primary key. When you insert sequential integer IDs, each new row goes at the end of the index — efficient.

When you insert fully random v4 UUIDs, each new row lands at a random position in the index. At scale this causes index fragmentation: the database constantly reshuffles pages, write performance degrades, and storage overhead grows. On high-throughput tables (millions of inserts per day), the difference is measurable.

The solutions:

• Use UUID v7 instead — time-ordered, so inserts go near the end of the index like sequential IDs
• Store UUIDs as BINARY(16) not VARCHAR(36) — cuts storage in half and speeds up comparisons
• Use a separate surrogate integer key internally and expose the UUID externally only

For most applications — under a few hundred thousand rows — v4 performance is completely fine. The fragmentation problem only matters at scale.

When to use UUID v4

Good fits:

• API resource identifiers exposed in URLs (/users/550e8400-...)
• Password reset tokens, magic login links, invite codes
• File names for uploaded content (prevents path traversal attacks)
• Distributed systems where multiple services generate IDs without coordination
• Any identifier that appears in client-facing contexts where sequentiality would leak information

Not the right choice:

• High-throughput database primary keys where insert performance matters — use v7 instead
• Human-readable references like order numbers or support ticket IDs — use sequential integers
• Situations requiring stable deterministic IDs from a known input — use v5

Generating UUID v4

In JavaScript (browser or Node.js):

crypto.randomUUID()

This is the native API available in all modern browsers and Node 14.17+. No library needed.

In Python:

import uuid
str(uuid.uuid4())

In PostgreSQL:

SELECT gen_random_uuid();

Or use the UUID Generator to generate one, ten, or a hundred UUID v4s instantly — with options for uppercase and no-hyphen formats.

Quick reference

• Format: 8-4-4-4-12 hex characters
• Version indicator: third group starts with 4
• Variant indicator: fourth group starts with 8, 9, a, or b
• Randomness: 122 bits
• Collision probability: negligible for any real workload
• Best for: tokens, file names, API IDs, distributed systems
• Avoid for: high-throughput DB primary keys (use v7), human-readable IDs (use integers)