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.

📅 Published July 2026· ⏳ 10 min read· ✍️ ToolsNovaHub Editorial Team
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

What is the most commonly used UUID version? +
Version 4 (fully random) remains the most widely used across general application development, due to its strong privacy properties and universal library support.
Is UUID v7 better than v4? +
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.
What makes UUID v5 different from v4? +
v5 is deterministic — hashing the same namespace and name input always produces the identical UUID, unlike v4's fully random, non-reproducible generation.
Does UUID v1 reveal my MAC address? +
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.
Can I convert between UUID versions? +
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.
Why would I choose v7 over v1 for sortability? +
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.
Is UUID v5 cryptographically secure? +
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.
What UUID version does most database software default to? +
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.
Can two different inputs produce the same v5 UUID? +
Theoretically possible due to SHA-1 hash collisions, but practically negligible for typical application use cases given the astronomically low collision probability.
Is v6 a real UUID version? +
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.
Which version should I use for a URL shortener's short codes? +
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.
Does UUID v4 have any downsides for database primary keys? +
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.
Can I generate the same v1 UUID twice on purpose? +
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.
Is there a UUID version optimized purely for privacy? +
v4 offers the strongest privacy since it embeds no timestamp, location, or sequence information whatsoever — purely random bits with no inferable metadata.
What version should a new project default to in 2026? +
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.
Explore All ToolsNovaHub Tools
🏠 Go to Homepage

🔗 More Guides