GUID / UUID V3 - Name-Based Identifier (MD5 Hash)
GUID / UUID v3 is a name-based identifier using MD5 hashing. Learn about its deterministic generation, structure, MD5 security concerns and why v5 is preferred for new systems.
GUID / UUID V4 - Random-Based Identifier (Recommended)
GUID / UUID v4 is the most widely used GUID / UUID version and is designed to be generated from randomness or a cryptographically secure pseudorandom generator. It requires no coordination, no central authority, no clock synchronization and no device identifiers. Making it ideal for distributed systems, APIs, databases and general-purpose unique identifiers.
Recommended: GUID / UUID v4 is the recommended choice for most general-purpose applications. It provides excellent uniqueness guarantees without requiring time-based ordering or deterministic generation.
Version status and history
GUID / UUID v4 was defined in the original GUID / UUID specifications around 1997 and standardized in RFC 4122 in July 2005.
V4 remains the most popular and widely recommended GUID / UUID version. It is fully supported in both RFC 4122 and RFC 9562 and has no deprecation concerns.
For applications requiring time-based sortability, consider v7 (Unix timestamp-based).
Advantages of GUID / UUID v4
- No coordination required: GUIDs / UUIDs can be generated independently on any machine without a central authority or database.
- High security and privacy: contains no timestamps, MAC addresses or embedded metadata that could reveal system information.
- Simple and widely supported: implemented in virtually all programming languages, databases, frameworks and platforms.
- Excellent for distributed systems: ideal for microservices, offline clients, cloud environments and multi-region architectures.
- Stateless generation: requires no counters, clocks or shared state, reducing complexity and failure modes.
- Fast and scalable: generation is usually CPU-cheap and parallel-friendly.
- Easy to validate: the version nibble and variant bits allow quick sanity checks during parsing.
Warnings and considerations
- Not sortable by time: v4 GUIDs / UUIDs are essentially random, so ordering does not reflect creation order. For time-based sorting, use v7.
- Index fragmentation risk: inserting random keys into some database indexes can cause page splits and slower writes (impact varies by database and configuration).
- Entropy source quality: security depends on a high-quality random number generator. Weak or predictable sources can compromise uniqueness guarantees.
- Not deterministic: the same input will not generate the same GUID / UUID.
Technical details
Bit layout: a GUID / UUID is 128 bits written in a canonical 36-character string format with 32 hexadecimal digits plus 4 hyphens (8-4-4-4-12). For v4, the value is mostly random bits, with a few reserved bits to indicate the version and variant.
Field structure: Although GUID / UUID v4 uses named fields from the original time-based layout (time_low, time_mid, time_hi_and_version, clock_seq, node), these fields are not interpreted as timestamps or MAC addresses in v4. They are effectively random bits except for the reserved version and variant bits.
Field structure
The 128-bit GUID / UUID v4 structure inherits field names from the time-based layout but fills them with random data:
Field Name Bits Hex Description
─────────────────────────────────────────────────────────────────────────
random_low 32 8 32 random bits
random_mid 16 4 16 random bits
random_hi_and_version 16 4 12 random bits + 4-bit version (0100)
random_seq_hi_and_reserved 8 2 2-bit variant (10) + 6 random bits
random_seq_low 8 2 8 random bits
random_node 48 12 48 random bits
Version bits: bits 12-15 of random_hi_and_version are set to 0100 (4 in hex), identifying this as a version 4 UUID.
Variant bits: bits 6-7 of random_seq_hi_and_reserved are set to 10, indicating RFC 4122 compliance.
Random bits: the remaining 122 bits are filled with random or pseudorandom data, providing 2¹²² = 5.3 × 10³⁶ possible unique values.
Try our GUID / UUID Inspector to decode and visualize the bit-level structure of v4 UUIDs.
Format and structure
GUID / UUID v4 uses the standard 8-4-4-4-12 canonical format with 32 hexadecimal digits separated by hyphens (36 characters total).
Canonical format: 8-4-4-4-12
Example (v4): 5c98eda8-b852-4eec-9960-ac2e29d734f4
Layout: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
^ ^
| └─ N = Variant: typically 8, 9, a or b (RFC variant)
└────── M = Version: first hex digit of 3rd group is "4" for v4
Practical rule: in the canonical string, the version is encoded as the first hex digit of the third group. For v4 it is 4. The variant is indicated by the high bits of the fourth group (often rendered as 8-b in hex). All other characters are random hexadecimal digits.
Randomness: a GUID / UUID is designed to be generated entirely from randomness or pseudorandom numbers.
A version-4 GUID / UUID has 122 bits of randomness (with 6 predetermined variant/version bits), providing 2¹²² possible combinations.
That's approximately:
5.3 × 10³⁶ unique values
To put this into perspective:
- The chance of two randomly generated GUIDs / UUIDs colliding is so small that it is considered mathematically negligible.
- Even if you generated 1 billion GUIDs / UUIDs per second, non-stop, for 100 years, the probability of producing a duplicate is still effectively zero.
- The GUID / UUID space is so large that every human on Earth could generate trillions of GUIDs / UUIDs without ever producing a duplicate
Frequently Asked Questions
GUID / UUID v4 is a random-based identifier that generates 128-bit unique values using a cryptographically secure random number generator. It requires no coordination between systems, no timestamps and no hardware identifiers. The algorithm fills 122 bits with random data and reserves 6 bits for version and variant markers, producing globally unique identifiers with negligible collision probability.
Use v4 for general-purpose unique identifiers in databases, APIs, distributed systems, and applications where time-based sorting is not required. It's ideal when you need privacy (no embedded metadata), simplicity (no clock synchronization) and independence (no coordination between systems). For time-sortable IDs, use v7.
The collision risk is astronomically low. With 122 random bits (2¹²² = 5.3 × 10³⁶ possible values), you'd need to generate approximately 2.7 × 10¹⁸ (2.7 quintillion) UUIDs before reaching a 50% collision probability. For practical applications, even generating billions of UUIDs per second for decades results in effectively zero collision risk.
No, v4 GUIDs / UUIDs are random and do not contain timestamp information. Sorting them does not reflect creation order. If you need time-based sorting, use v7 (Unix timestamp prefix).
No, v4 GUIDs / UUIDs contain only random bits and do not embed timestamps, MAC addresses, IP addresses or any other identifiable information. This makes them suitable for privacy-sensitive applications. Unlike v1 (which includes MAC addresses) or v7 (which includes timestamps), v4 reveals nothing about when, where or by whom it was generated.
A weak or predictable random number generator can compromise uniqueness guarantees and potentially allow collision attacks. Always use a cryptographically secure pseudorandom number generator (CSPRNG) such as
/dev/urandom on Linux, CryptGenRandom on Windows, or language-specific secure random functions (crypto.randomBytes in Node.js, secrets module in Python).Yes, and it's commonly done in distributed systems. However, be aware of potential index fragmentation with some databases (especially B-tree indexes) because random keys cause non-sequential inserts. Some databases handle this well (e.g., PostgreSQL), while others may see performance impacts. For better database performance with sequential inserts, consider v7.
Most languages have built-in or standard library support:
- JavaScript/Node.js:
crypto.randomUUID() - Python:
import uuid; uuid.uuid4() - Java:
UUID.randomUUID() - C#:
Guid.NewGuid() - Go:
uuid.New()(with google/uuid package) - Rust:
Uuid::new_v4()(with uuid crate)
No, v4 GUIDs / UUIDs should not be used as security tokens, session IDs, passwords, or cryptographic keys. While they have high entropy, they are not designed for cryptographic security. For security-sensitive applications, use dedicated cryptographic functions designed for token generation, such as
crypto.randomBytes() with sufficient length (256+ bits) and proper encoding.Conclusion
GUID / UUID v4 is the recommended choice for most general-purpose applications. It provides excellent uniqueness guarantees without requiring time-based ordering, deterministic generation, or coordination between systems. From databases and distributed systems to cloud services and APIs, v4 GUIDs / UUIDs offer simplicity, privacy, and scalability.
Learn more
These articles expand on related concepts, formats and practical considerations.