UUID v1 vs v4 vs v5: Which Version Should You Use?
Quick Answer
Use UUID v4 (random) by default — it needs no coordination and has negligible collision risk. Use v1 (time-based) only when you need time-orderable IDs and can secure the node ID. Use v5 (namespace+name) when you need deterministic IDs derived from a name. Generate any version with our free UUID Generator.
Introduction
A UUID (Universally Unique Identifier) is a 128-bit identifier rendered as 36 characters in 8-4-4-4-12 hex groups, e.g. 123e4567-e89b-12d3-a456-426614174000. RFC 9562 defines several versions; the three you will encounter most are v1 (time + MAC), v4 (random), and v5 (namespace + name, SHA-1). Each makes different trade-offs between uniqueness guarantees, sortability, and determinism.
Step by Step
-
UUID v1 — time and node based
v1 encodes the current 60-bit timestamp (100-ns intervals since 1582-10-15) and a 48-bit node ID (usually the MAC address). IDs generated on the same node are monotonically increasing and time-sortable. Risk: the MAC address leaks hardware identity, and clock-skew across nodes can break ordering.
-
UUID v4 — random
v4 uses 122 random bits (6 bits are fixed for the version/variant). With 122 random bits, the probability of a collision among 2.71 trillion IDs is 50% — for any realistic workload the chance is effectively zero. v4 needs no coordination and reveals no host information, making it the safest default.
-
UUID v5 — namespace and name (SHA-1)
v5 hashes a namespace UUID and a name string with SHA-1 to produce a deterministic 128-bit ID. The same (namespace, name) pair always yields the same UUID, which is ideal for deduplication and stable IDs derived from natural keys. v3 is the same idea but uses MD5 (avoid it).
-
Compare the trade-offs
v1 is sortable but leaks MAC and needs clock sync. v4 is random and private but unsortable. v5 is deterministic and deduplicates but is not random — guessing the name lets an attacker reproduce the UUID. Choose based on whether you need ordering, randomness, or determinism.
-
Pick the right version for your case
Database primary keys: v4 (or v7 in newer systems for time-orderability). Distributed systems without coordination: v4. Deterministic IDs from a natural key (e.g. URL → UUID): v5. Audit logs that benefit from time order: v1 with a secured random node ID.
Examples
UUID v1 (time-based, sortable)
Input: Generated at 2026-08-28T12:00:00Z on node 00:11:22:33:44:55
Output: 1ef7c1d0-2d3b-11f0-8000-001122334455 (version digit '1', time-sortable)
UUID v4 (random)
Input: Random generation
Output: f47ac10b-58cc-4372-a567-0e02b2c3d479 (version digit '4', random bits)
UUID v5 (deterministic from namespace+name)
Input: Namespace DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8) + name 'firetools.online'
Output: 74738ff5-5367-5958-9aeb-0c1f1f1f1f1f (same input always yields same output)
Common Problems
- Storing UUIDs as VARCHAR(36) instead of a native 16-byte BINARY/UUID type: this wastes 2x storage and breaks index performance. Use a native UUID column type where available.
- Using v1 without securing the node ID: the default MAC address leaks hardware identity and is a privacy concern. Replace it with a cryptographically random 48-bit value per node.
- Assuming v4 collisions are impossible: they are not — they are just astronomically unlikely. With 122 random bits, you need ~2.71 trillion IDs for a 50% chance. For 1 billion IDs the chance is ~0.0000000000000001.
- Using v3 (MD5-based) instead of v5 (SHA-1-based): MD5 is broken, so v5 is preferred. Both are deterministic, but v5 has stronger collision resistance.
Tips
- Default to v4 for almost every use case — it is random, private, and collision-safe without any coordination.
- If you need time-sortable random IDs, look at UUID v7 (RFC 9562, 2024) which combines a Unix timestamp with random bits — better than v1 for modern databases.
- Use v5 to generate stable IDs from natural keys (URLs, email addresses) so the same input always maps to the same UUID — useful for deduplication and idempotent APIs.
- Generate UUIDs on the client when possible to avoid a round-trip to the server — our UUID Generator runs entirely in your browser using crypto.getRandomValues().