What Is a UUID v4?
A UUID v4 (version 4 universally unique identifier, sometimes written uuid4) is a 128-bit value built almost entirely from random numbers, as defined in RFC 4122. Of those 128 bits, 122 are pure randomness — the remaining 6 mark the version ("4") and variant, so any parser can confirm the type at a glance. For native UUID column type and gen_random_uuid() support, see the postgresql uuid guide.
Because it embeds no timestamp, MAC address, or other metadata, a UUID v4 generator produces identifiers that reveal nothing about when or where they were created — a real privacy advantage over version 1.
UUID v4 Structure and Format
Every randomly generated UUID of this type follows the same 8-4-4-4-12 hexadecimal layout, with two fixed positions marking version and variant:
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
Where:
4 = Version 4 (always "4")
y = Variant (8, 9, a, or b)
x = Random hexadecimal digit (0-9, a-f)
Example: f47ac10b-58cc-4372-a567-0e02b2c3d479
How to Spot a Version 4 Identifier
- The 13th character (first character of the third group) is always "4"
- The 17th character (first character of the fourth group) is "8", "9", "a", or "b"
- Every remaining character is an independently random hex digit
How Unique Is a UUID v4? Collision Probability
A random uuid generator is only trustworthy if collisions are effectively impossible — and the math backs that up. With 122 random bits, there are 2122, roughly 5.3 undecillion, possible values. See the python uuid page for UUID validation, bytes/int/hex conversion, and SQLAlchemy column integration.
Total Possible Values
5.3 × 1036
50% Collision Probability At
2.71 × 1018
identifiers generated (2.71 quintillion)
Real-World Perspective
- • 1 billion generated per second: ~86 years to reach a 50% collision probability
- • 1 million per day for 100 years: collision probability stays around 10-24
Trade-Offs: UUID v4 Against v1 and v7
Picking uuid version 4 means trading sortability for unpredictability. Here's exactly what you gain and give up: The uuid v7 generator combines a Unix millisecond prefix with random bits — time-sorted and collision-resistant.
| Feature | UUID v4 | UUID v1 | UUID v7 |
|---|---|---|---|
| Generation Method | Random numbers | Timestamp + MAC | Unix time + random |
| Time-Sortable | No | Partially | Yes |
| Privacy | Excellent | Poor (exposes MAC) | Good |
| Database Index Performance | Poor (random) | Moderate | Excellent |
Privacy: Why v4 Beats v1
A version 1 identifier embeds the generating machine's MAC address and a precise creation timestamp — both leak real information if the ID ever appears in a public URL or API response. A randomly generated UUID like v4 carries none of that, which is why it's the default choice for anything user-facing.
Index Performance: Why v7 Beats v4
UUID v7 places a Unix millisecond timestamp in the leading bits, so new values insert roughly in order. A UUID v4 generator has no such structure — every value lands at a random point in sort order, which is the root cause of the index fragmentation covered next.
When to Use (and Avoid) UUID v4
A Good Fit
- • Session tokens and API keys — unguessable by design
- • User-facing IDs in URLs — don't leak signup order
- • File names and object storage keys — no naming scheme needed
- • Password-reset and email-verification links (with an expiry)
Consider an Alternative
- • High-write database primary keys — v7 avoids index fragmentation
- • Chronological ordering needed — v1 or v7 instead
- • Deterministic, reproducible IDs — v5 instead
UUID v4 in Databases
A UUID v4 works as a primary key in any relational or document store, but its randomness comes with a well-known cost on high-write tables.
The B-Tree Fragmentation Problem
Most relational databases store primary keys in a B-tree index, which performs best when new values arrive in roughly ascending order. A random uuid breaks that assumption completely — each insert lands at an unpredictable point in the index rather than at the end.
How Random Inserts Cause Page Splits
When a new uuid4 value falls in the middle of an already-full index page, the database has to split that page in two to make room. At scale, this generates extra disk I/O, bloats the index beyond what the data alone would need, and hurts cache locality since related rows end up scattered across disk rather than stored near each other.
Reducing the Impact
- For new schemas on high-write tables, prefer UUID v7 — its timestamp prefix keeps inserts roughly sequential
- If you're locked into v4, consider a separate auto-incrementing clustering key with the UUID as a secondary unique column
- For read-heavy, low-write tables, v4's fragmentation cost is rarely noticeable in practice
For full setup instructions, see our python uuid, postgresql uuid, and mysql uuid guides.
Frequently Asked Questions
Is UUID v4 really random?
Yes, when generated correctly. This tool uses crypto.randomUUID(), backed by a cryptographically secure random number generator (CSRNG) — the same class of source used for encryption keys. Avoid generators built on Math.random(), which isn't cryptographically secure.
What's the difference between UUID v4 and a GUID?
None functionally. A random GUID (Microsoft's term) and a UUID v4 are the same 128-bit format defined by RFC 4122 — interchangeable in any tool or library.
Can two systems generate the same UUID v4?
Theoretically yes, practically no. The odds are roughly 1 in 2122 — astronomically less likely than winning a major lottery jackpot several times in a row.
Should I use UUID v4 for database primary keys?
It works, but its randomness can fragment B-tree indexes on high-write tables. Fine for low-to-medium volume tables; for high-volume tables, UUID v7 gives better index locality.
How do I validate a UUID v4?
Check that it's 36 characters with hyphens at positions 8, 13, 18, and 23, the 13th character is "4", and the 17th is "8", "9", "a", or "b" — or run it through our UUID Validator for an instant check.