UUID Versions Guide: v1 vs v4 vs v5 vs v7 Compared

Not all UUIDs are generated the same way. Here's exactly how each version works, and a clear answer for which one fits your specific use case.

✍️ Author: ToolsNovaHub • 📅 Last Updated: 1 July 2026 • ⌛ 10 min read
The UUID specification (RFC 9562) defines several distinct generation methods, called versions, each embedded as a marker within the UUID itself. Picking the right version matters more than most developers realize — it affects sortability, privacy, and even database index performance at scale.
📑 Table of Contents

Version 1: Timestamp + Node

UUID v1 combines the current timestamp (100-nanosecond intervals since October 15, 1582 — the Gregorian calendar's start date, chosen for historical compatibility with earlier timestamp systems) with a node identifier, originally the machine's MAC address. This makes v1 UUIDs naturally sortable by creation time, but the original MAC-based approach leaked hardware identity information — most modern implementations now use a random node ID instead to avoid this privacy issue.

Version 4: Random

The most widely used version. 122 bits are filled with cryptographically random data (6 bits are fixed to mark version and variant). No ordering, no embedded information — purely random, offering the strongest privacy of any version since nothing about when or where it was generated can be inferred.

Version 5: Name-Based (Deterministic)

Generated by SHA-1 hashing a namespace UUID combined with a name string. Critically, v5 is deterministic — the same namespace and name always produce the exact same UUID. This makes it useful for generating a stable, repeatable identifier from existing data, like turning a URL or email address into a consistent UUID without needing to store a separate mapping table.

Version 7: Sortable Random

The newest widely-adopted version, combining a millisecond-precision Unix timestamp prefix with random bits for the remainder. This gives v7 the best of both worlds: chronological sortability like v1, without the node-identifier privacy concerns, plus strong randomness in the non-timestamp portion. Database index performance benefits significantly since new v7 values append in roughly ascending order rather than scattering randomly like v4.

Side-by-Side Comparison

VersionSortableDeterministicPrivacyIndex-Friendly
v1YesNoWeaker (timestamp exposed)Yes
v4NoNoStrongestNo — fragments indexes
v5NoYes (from same input)Depends on inputNo
v7YesNoStrongYes

Which Version Should You Use?

  • Building a new system with no legacy constraints: v7 is increasingly the recommended default — sortable, index-friendly, and privacy-respecting.
  • Need a stable ID derived from existing data (like a URL): v5, since the same input always regenerates the same UUID without needing a lookup table.
  • Maximum unpredictability, no ordering needed: v4 remains the safe, universally-supported default, especially for session tokens or API keys where guessability matters most.
  • Working with a legacy system already using v1: Stick with v1 for consistency unless you have a specific reason to migrate.

Generate v1 or v4 UUIDs instantly with our UUID Generator.

FAQs

Version 4 (fully random) remains the most widely used across general application development, due to its strong privacy properties and universal library support.
It depends on your needs — v7 offers sortability and better database index performance, while v4 offers slightly stronger unpredictability since it has no embedded timestamp at all. Many new systems are adopting v7 as the default.
v5 is deterministic — hashing the same namespace and name input always produces the identical UUID, unlike v4's fully random, non-reproducible generation.
The original specification did use the MAC address as the node identifier, which was a real privacy concern. Modern implementations typically substitute a randomly generated node ID instead to avoid this leak.
No — versions represent fundamentally different generation methods, not an encoding you can convert between. You'd need to generate a fresh UUID in the desired version.
v7 uses a modern millisecond Unix timestamp with strong random bits and no node-identifier privacy concerns, making it the more modern choice when sortability is needed without v1's historical baggage.
It uses SHA-1, which is considered weak for cryptographic security purposes generally, but for the specific purpose of generating a deterministic identifier (not for security-sensitive hashing), it remains acceptable and standard.
Most database UUID-generation functions (like PostgreSQL's gen_random_uuid()) default to v4 unless you explicitly request a different version through a specific function or extension.
Theoretically possible due to SHA-1 hash collisions, but practically negligible for typical application use cases given the astronomically low collision probability.
Yes — v6 is a field-compatible reordering of v1 designed for better sortability while remaining closer to v1's structure; it's less commonly adopted than v7 in new systems.
UUIDs generally aren't ideal for user-facing short codes regardless of version, since they're long and hard to read aloud — a separate short, base62-encoded ID scheme is usually better for that specific use case.
Yes — its fully random distribution can fragment B-tree indexes since new rows insert at random positions rather than appending sequentially, which is one of the main reasons v7 has gained popularity.
No — v1 always incorporates the current timestamp at generation time, so generating it again even moments later produces a different value, unlike v5's fully deterministic behavior.
v4 offers the strongest privacy since it embeds no timestamp, location, or sequence information whatsoever — purely random bits with no inferable metadata.
For most new projects without specific legacy constraints, v4 remains a safe universal default, while v7 is the increasingly recommended choice specifically when database performance and natural sort order matter.
📅 Last updated: July 2026

ToolsNovaHub guides are researched against primary sources (RFCs, vendor docs) and kept up to date as standards change. Spotted an error? Let us know.

📋 Related Tools & Guides Comparison

ResourceTypeLink
UUID GeneratorToolOpen Tool →
UUID vs GUID ExplainedGuideRead Guide →
UUID Primary Key GuideGuideRead Guide →
MAC Address GeneratorToolOpen Tool →
🔗 Continue exploring: UUID Generator · UUID vs GUID Explained · UUID Primary Key Guide · MAC Address Generator
Explore All ToolsNovaHub Tools
🏠 Go to Homepage

🔗 More Guides