UUID Guide: v4 Random vs v3/v5 Namespace UUIDs Explained (2026)
📅 August 2026⏱ 8 min read✍️ ToolLoom Editorial
Most developers use UUID v4 by default and never think about it again — which is usually the right call. But when you actually need the same identifier every time for the same input, v4's randomness becomes a problem, not a feature. Here's how the versions differ and when each one actually matters.
A UUID (Universally Unique Identifier) is a 128-bit value designed to be unique across systems, servers, and time — without any central authority coordinating who gets which number. This is what makes UUIDs so useful in distributed systems: any server, anywhere, can generate one independently with virtually no risk of colliding with an ID generated somewhere else.
🌐
No Central Authority
Any machine can generate a valid, unique UUID independently.
🔑
Database Primary Keys
Widely used instead of auto-incrementing integers in distributed databases.
🔀
Multiple Versions
v4 (random) and v3/v5 (deterministic) serve genuinely different purposes.
📐
Standardised (RFC 4122)
Defined format ensures compatibility across every language and platform.
Anatomy of a UUID String
A UUID is displayed as 36 characters: 32 hexadecimal digits arranged in five groups separated by hyphens, in the pattern 8-4-4-4-12.
Example UUID
550e8400-e29b-41d4-a716-446655440000
Despite the 36-character display length (including hyphens), the actual information content is 128 bits. A specific digit within the string (the first character of the third group) indicates the UUID's version — telling you whether it was generated randomly (v4) or deterministically (v3/v5), among other possible versions.
UUID v4 — Random Generation
UUID v4 is the version most developers reach for by default. It's generated using a cryptographically secure random number source, filling 122 of the 128 bits with pure randomness (the remaining 6 bits are fixed to mark the version and variant). Call it twice with no input at all, and you'll get two completely unrelated values — there's no way to reproduce the same UUID again.
💡
v4 is the right default for general-purpose unique identifiers: database record IDs, request IDs, session tokens, file names — anywhere you just need "a unique value," with no requirement that the same input produce the same output later.
UUID v3/v5 — Deterministic Namespace Generation
v3 and v5 work completely differently from v4 — there's no randomness involved at all. Instead, they combine a namespace UUID with a name string and run the combination through a hash function. The same namespace and name always produce the exact same UUID, every single time, on any machine.
Version
Hash Algorithm
Recommendation
v3
MD5
Exists for backward compatibility — MD5 is cryptographically weak
v5
SHA-1
Preferred over v3 — use this whenever you have the choice
RFC 4122 defines four standard predefined namespace UUIDs for common cases — DNS names, URLs, ISO OIDs, and X.500 distinguished names — which get combined with your specific input name to compute the final v3/v5 UUID.
Collision Probability — The Actual Math
UUIDs aren't mathematically guaranteed to be unique — but the probability of an accidental collision is low enough to be considered effectively impossible for real-world use. Using the birthday paradox calculation applied to v4's 122 random bits:
50% Collision Probability
≈ 2.71 quintillion (2.71 × 10¹⁸) UUIDs generated
✅
To put that number in perspective: even generating a billion UUIDs per second, it would take roughly 86 years of continuous generation before reaching even a 50% chance of a single collision. For virtually any practical application, treating v4 UUIDs as unique is a completely safe assumption.
Worked Example — Same Input, Same Output
Suppose a system needs a consistent, unique ID for the URL https://example.com/products/widget-42, without maintaining a separate lookup table mapping URLs to IDs.
Approach
Result
Generate with UUID v4
A different random UUID every time it's called — unusable for this purpose
Generate with UUID v5 (URL namespace + the URL as name)
The exact same UUID every time, computed fresh from the URL itself
✅
With v5, any service that knows the URL can independently compute the identical UUID without ever querying a database — genuinely useful for caching keys, content-addressable storage, and de-duplication across distributed systems. Try ToolLoom's UUID Generator to generate both v4 and v3/v5 UUIDs instantly, including bulk generation.
When to Use v4 vs v3/v5
Database primary keys (general) — v4, since no determinism is needed
Session or request identifiers — v4, for unpredictable, one-off values
De-duplicating resources by name or URL — v5, so identical inputs always resolve to the identical ID
Content-addressable storage or caching keys — v5, to compute the same key independently across services
Interfacing with legacy systems expecting v3 — v3, purely for compatibility, otherwise prefer v5
File names, temporary tokens, one-time codes — v4, for unpredictability
Common UUID Mistakes
Using v4 when you actually need determinism — leads to duplicate records because the "same" resource gets a new ID every time
Using v3 instead of v5 without a compatibility reason — v5's SHA-1 basis is preferable to v3's weaker MD5
Assuming UUIDs sort meaningfully by creation time — standard v4/v5 UUIDs don't encode time ordering; use UUID v7 or a dedicated timestamp column if sort order matters
Treating a UUID as a strong security secret without considering context — fine for session identifiers, but purpose-built tokens remain safer for highly sensitive authentication
Not using a proper namespace for v5 — using an ad-hoc string instead of a real namespace UUID undermines the standard's collision guarantees
💻 Generate UUIDs Instantly — Free
Bulk v4 random UUIDs or deterministic v3/v5 namespace UUIDs — runs entirely in your browser.
A UUID is displayed as 36 characters: 32 hexadecimal digits arranged in five groups separated by hyphens, in the pattern 8-4-4-4-12 — for example, 550e8400-e29b-41d4-a716-446655440000. Despite the 36-character display length, a UUID is a 128-bit value underneath; the hyphens are just formatting for readability.
v4 is purely random — call it twice with no input and you get two completely unrelated UUIDs, with no way to reproduce the same value again. v5 is deterministic — it's computed from a namespace UUID plus a name string using the SHA-1 hash algorithm, so calling it with the exact same namespace and name always produces the identical UUID every single time, with no randomness involved at all.
Extremely unlikely, though not mathematically impossible. A version 4 UUID has 122 bits of actual randomness (6 bits are fixed to mark the version and variant). Using the birthday paradox calculation, you would need to generate roughly 2.71 quintillion UUIDs before there's even a 50% probability of one collision occurring — a number large enough to be considered effectively impossible for any realistic application.
Use v5 rather than v3 whenever you have the choice. Both work identically in concept — combining a namespace UUID with a name string to produce a deterministic identifier — but v3 uses the MD5 hash algorithm, which is considered cryptographically weak, while v5 uses SHA-1, which remains adequate for this non-security-critical use case. v3 exists mainly for backward compatibility with older systems.
A version 4 UUID generated with a cryptographically secure random source has 122 bits of entropy, which is generally considered strong enough to resist guessing for uses like session identifiers. However, for highly sensitive authentication tokens (like password reset links or API secrets), purpose-built token generation methods are still the safer, more conventional choice, since UUIDs weren't specifically designed as security tokens.
UUIDs can be generated independently on multiple servers or client devices without any risk of collision or need for central coordination, unlike auto-incrementing integers which require a single authoritative counter. This makes UUIDs well suited to distributed systems, offline-first applications, and microservices architectures where multiple services need to create new records without checking in with a central database first.
About ToolLoom: We build free tools for Indian students, professionals and creators. All UUID generation happens instantly in your browser via the Web Crypto API — nothing is uploaded or stored. Found an error? Email contact@toolloom.in